Create a PowerApps Component Framework (PCF) component
- initialize a new PCF component
- configure a PCF component manifest
- implement the component interfaces
- package, deploy, and consume the component
- use Web API device capabilities and other component framework services
The development technologies involved as part of PCF components differ significantly from the areas that traditional Dynamics CRM developers will likely know. Therefore, let’s jump in to review this in further detail and, similar to last week’s post, focus on demonstrating how to deploy a simple PCF control out into the platform.
PCF Controls Overview
To help address the traditional needs of Web Resources and, additionally, allow us to overhaul the appearance within model-driven Power Apps completely, Power Apps Component Framework (PCF) controls are now here and ready to be used. They were introduced relatively recently and are currently in general availability for model-driven Power Apps. Because they take advantage of a whole heap of existing tools, developers can quickly bundle together re-usable custom components and deploy them multiple times across a model-driven app. These can not only alter the behaviour of the elements described earlier (fields & views), but also support additional capabilities, such as the ability to access the applications Web API. Some of the advantages they have over traditional Web Resources include:
- The ability to bundle all aspects of your project together into a single solution file.
- Because the application renders custom controls at the same time as the form itself, users get a completely seamless experience when using a model-driven app.
- They are developed using modern web technologies, such as NPM, Node.js and TypeScript.
- (Eventual) support for all types of Power Apps, both model and canvas.
Now, PCF controls are great but are not necessarily the most accessible tool to implement. Developers should evaluate the requirements of the overall solution and, where possible, guide an organisation towards introducing a canvas Power App instead, if that meets the requirements. To best illustrate how to make this decision, let’s consider the following two scenarios:
- The organisation requires a highly tailored area within the Account form to create new Contact’s that will then be related to the parent record: Given there are numerous controls to implement, an embedded canvas app is the most straightforward solution here.
- You’re managing a multi-lingual instance and need to ensure that all controls display in the user’s chosen language: Although this is possible to do via a canvas app, a PCF control is a more logical approach, given it can hook into the applications localisation settings.
- The organisation has an existing Node.js/Angular web component on their website that they wish to replicate across into Dynamics 365: In this situation, a PCF control makes logical sense, as we can straightforwardly port this across to the application with minimal effort.
- Your solution needs to immediately trigger and return feedback from actions triggered via Power Automate flows: As it stands, only canvas apps support this capability.
A good Dynamics 365 / Power Platform can build out a PCF control without issue; the sign of an excellent developer is identifying the appropriate usage cases for them, and in not necessarily resorting to them as a first-preference solution, if others can fit the gap.
Technology Areas Involved
PCF controls are an anomaly, to a degree, when you start looking at the technology areas that make them up. I would forgive you for assuming that they rely solely on .NET focused programming languages. Instead, they utilise some more recently developed languages targeted towards rapid web development. This circumstance can be potential blocker when learning about PCF controls for the first time, but it is a hump that is worth surmounting. The below list covers all of the languages and tools that help bring PCF controls together. It is impossible to provide a detailed overview of the inner workings of each of these as part of a single blog post, so I encourage you to perform separate revision in these areas; what follows, therefore, is a basic overview:
- NPM: Node Package Manager (NPM) is used within PCF controls to retrieve common, pre-built libraries/packages of functionality so that you do not necessarily have to reinvent the wheel when developing your code component for the first time. For example, rather than building a calendar control from scratch, you could instead use FullCalendar by downloading its appropriate NPM packages and then referencing the components you need within TypeScript.
Before you can start writing a single line of code, you need to ensure you have ticked a few boxes on your machine:
- You must have either NPM or Node.js installed on your computer. I recommend using NPM, as this includes Node.js as standard. During installation, be sure to tick the option to download additional tools, one of which installs Visual Studio 2017 Build Tools. After this has installed, be sure to go into the Visual Studio 2017 installer and add on the individual component NuGet targets & Build Tasks, an additional pre-requisite.
- You must also have the .NET Framework 4.6.2 Developer Pack installed on your machine.
- Finally, a specific CLI for developing PCF controls must be installed. The CLI will provide a range of commands to build, test and deploy your components as you build them out.
You must also make an important decision regarding which integrated development environment (IDE) you wish to use to develop your control – either Visual Studio 2017 (or later) or Visual Studio Code. Although the latter option does require some tinkering, I recommend it over traditional Visual Studio if at all possible, as it provides a far more streamlined development experience. Also, note that you will need to install the .NET Core 3.1 SDK if using Visual Studio Code.
Once you have installed all pre-requisite components, you can then initialise and create your first PCF component project. You can follow the steps outlined in this article to get started. Alternatively, check out the video below to see this, and all other steps mentioned so far in this section, in action:
Reviewing the PCF Component Manifest
Just as solutions have high-level properties/metadata that summarises your particular piece of functionality, a PCF component has a manifest which defines general properties relating to your component. Comprised of a single file, called ControlManifest.Input.xml, the manifest looks like this when creating a new component targeting a field:
<?xml version="1.0" encoding="utf-8" ?> <manifest> <control namespace="jjg" constructor="MB400Sample" version="0.0.1" display-name-key="MB400Sample" description-key="MB400Sample description" control-type="standard"> <!-- property node identifies a specific, configurable piece of data that the control expects from CDS --> <property name="sampleProperty" display-name-key="Property_Display_Key" description-key="Property_Desc_Key" of-type="SingleLine.Text" usage="bound" required="true" /> <!-- Property node's of-type attribute can be of-type-group attribute. Example: <type-group name="numbers"> <type>Whole.None</type> <type>Currency</type> <type>FP</type> <type>Decimal</type> </type-group> <property name="sampleProperty" display-name-key="Property_Display_Key" description-key="Property_Desc_Key" of-type-group="numbers" usage="bound" required="true" /> --> <resources> <code path="index.ts" order="1"/> <!-- UNCOMMENT TO ADD MORE RESOURCES <css path="css/MB400Sample.css" order="1" /> <resx path="strings/MB400Sample.1033.resx" version="1.0.0" /> --> </resources> <!-- UNCOMMENT TO ENABLE THE SPECIFIED API <feature-usage> <uses-feature name="Device.captureAudio" required="true" /> <uses-feature name="Device.captureImage" required="true" /> <uses-feature name="Device.captureVideo" required="true" /> <uses-feature name="Device.getBarcodeValue" required="true" /> <uses-feature name="Device.getCurrentPosition" required="true" /> <uses-feature name="Device.pickFile" required="true" /> <uses-feature name="Utility" required="true" /> <uses-feature name="WebAPI" required="true" /> </feature-usage> --> </control> </manifest>
The properties in control node are specified when creating your project for the first time using the pac pcf init command. Typically, the only values in this node you would change is the version, display-name-key and description-name key values. The version value should be updated each time you deploy an updated version of your component.
The manifest includes some additional nodes, which are worth reviewing in further detail:
- property: Here, you define the various input properties that the component relies on and will be ultimately bound to when utilised. You can only tie PCF controls to a limited range of field types within the application, so it’s essential to know the limitations relating to this. For example, at the time of writing this post, it is not possible to bind a control to a lookup, Status or Status Reason field. You have additional options here to specify whether a property requires a value and whether the component should utilise a default value if none is specified. A PCF component can have multiple property nodes defined for it.
- resources: Within this node, you must list all files that the component relies on to function correctly – whether this is additional HTML, CSS, or even other file types, such as images. Only one TypeScript file can be listed here, but you can have as many of all different file types as your component needs to function correctly.
- feature-usage: Here, you can enable/disable additional features that your component can utilise within a model-driven app. By default, all of these are disabled, so you will need to uncomment the specific ones you need. Note, in particular, that you must explicitly enable the WebApi for use in your component before you can start calling its appropriate list of methods.
Just as you need to spend some time updating the properties of your solution each time your release, you should anticipate working in the manifest often. For the exam, having a good awareness of the manifest schema and how to enable/disable various properties within your code component should be sufficient.
End to End Development Cycle: Building, Debugging and Deploying a PCF Control
Microsoft provides a great online tutorial, that talks you through the steps involved to build your very first PCF Control, so there is no point me repeating this verbatim. However, I sometimes find the best way to understand a process is to see it in action. With this in mind, check out the video below, where I will guide you through all the steps involved to deploy out your very first PCF control into a model-driven app. The video will also show you how to debug your code component using the Power Apps Component Framework Test Environment:
This state of affairs means that if, for example, you need to perform operations such as an Execute request, you would have to instead resort to a solution that uses client-side scripting instead.
Coming Soon: PCF Controls for Canvas Apps
A final note and, one which Microsoft will (I assume) eventually cover within the MB-400 exam itself, is that PCF controls are supported within canvas Power Apps as well. This capability is currently in public preview but, once released, will allow developers to straightforwardly utilise an existing PCF control within their canvas apps, without needing to rewrite their code. To find out more how to get started with this feature, check out the following Microsoft Docs article.
Further Tools / Resources
I’ve linked to numerous Microsoft Docs articles in this post surrounding PCF control development, and these should always be your first port of call when getting started on this subject. I would also recommend that you check out the following other resources too:
- PCF Gallery: A free community website operated by Guido Preite, this site is an excellent resource for finding free PCF controls, that you can utilise or experiment further with.
- Dynamics Ninja Blog: Ivan Ficko has blogged, delivered many sessions relating to PCF controls and also has numerous examples that he’s created as well. If you’re looking to go the next step with your PCF development, he is your man! 🙂
- Todd Baginski’s YouTube Channel: Todd has also done videos on how to develop a PCF control and debug your components, which I would recommend watching.