Rajeev Pentyala – Microsoft Power Platform

While unregistering one of my custom plug-in assemblies from the Plugin Registration Tool (PRT), I got the following error:

Invalid plug-in registration stage. Steps can only be modified in stages BeforeMainOperationOutsideTransaction, BeforeMainOperationInsideTransaction, AfterMainOperationInsideTransaction and AfterMainOperationOutsideTransaction.

Reason:

• Plug-in Assembly (CAT.APIs), I was trying to unregister has a Custom API plug-in (CAT.APIs.ExecuteOnBoardCustomerAPI). Refer my previous article on how to create and register Custom API).

• Which means, a Dataverse Custom API record already, mapped with the Plug-in CAT.APIs.ExecuteOnBoardCustomerAPI in the background. Refer ‘Plugin Type’ column below.

• Hence we can’t unregister the CAT.APIs Assembly without un-mapping the CAT.APIs.ExecuteOnBoardCustomerAPI from the Dataverse Custom API record.

Fix:

• Either un-map (i.e., Clear the ‘Plugin Type’ column) the CAT.APIs.ExecuteOnBoardCustomerAPI from the Dataverse Custom API record as below.

• Or delete the Dataverse Custom API record.
• Proceed with unregistering the Plug-in Assembly from Plugin Registration Tool and it should unregister now.

If you are looking for downloading and launching Plugin Registration Tool, please refer article here.

🙂

I often get this question “Why Interfaces”, can’t I simply implement logic just with Class from C# beginners?.

Well, If you search this questions over internet, you get the following overwhelming response:

In C#, interfaces are a way to specify a contract that a class must implement. They allow you to define a set of methods that a class must implement, without specifying how those methods should be implemented. This is useful for several reasons:

1. Interfaces allow you to create a common set of methods that can be used across multiple classes, even if those classes have very different implementations.
2. Interfaces allow you to write code that is more flexible and adaptable, because it is not tied to a specific implementation of a class.
3. Interfaces can be used to model real-world concepts in your code, such as the concept of a “drawable” object that can be drawn to the screen.
4. Interfaces can be used to create a level of abstraction between different parts of your code, which can make it easier to understand and maintain.

Overall, interfaces are a powerful feature of C# that can help you write more flexible, reusable, and maintainable code.

Why Interfaces in C#?

In this article, I will try to explain a very basic use of Interface out of many other benefits.

Scenario:

Assume that you are building a Shopping Cart functionality for a Car Show room, which ships both Electric and Gas Cars and you want build functionality to add cars to the Cart and Ship them.

That’s the scenario and I will demonstrate this scenario with a simple C# console project.

Implementation:

We will first start with defining ‘Entity Model’ and then move on to Cart functionality.

Entity Model :

• As we know that ‘Electric Car’ and ‘Gas Car’ contain both common and different features, So I decided to go with two classes ElectricCar and GasCar.
• Class ‘ElectricCar‘ looks as below:

• Class ‘GasCar‘ looks as below:

• If you notice, “FullChargeTimeInHours” property is in ‘ElectricCar‘ but not in ‘GasCar‘ and “CapacityInLiters” property is in ‘GasCar’ but not in ‘ElectricCar‘.
• Lets implement a simple ‘Cart’ functionality by:
  • Add items to Cart
  • And ship them using ‘Ship()’ function

Cart Logic (No Interface):

• Add a new function AddElectricCars() which returns list of Electric Cars.

• Add a new function AddGasCars() which returns list of Gas Cars.

• Now call AddElectricCars() and AddGasCars() and loop through Cars and invoke Ship() function.

• If you observe, both ‘ElectricCar‘ and ‘GasCar‘ classes have same properties and function (i.e., Ship) except one property, we had to implement 2 Carts logic.
• Now lets see how this can be simplified using Interfaces.

Cart logic (using Interface):

• Create a new ‘ICar’ interface with common properties and function between ‘ElectricCar‘ and ‘GasCar‘.

• Implement ‘ICar’ interface in ‘ElectricCar‘ class.
  • Notice that I’ve defined ‘FullChargeTimeInHours’ property which is specific to ‘ElectricCar‘ with in the Class.

• Similarly implement ‘ICar’ interface in ‘GasCar‘ class.
  • Notice that I’ve defined ‘CapacityInLiters’ property which is specific to ‘GasCar‘ with in the Class.

• Now lets see the magic. We can have a single Cart which handles both ‘ElectricCar‘ and ‘GasCar‘.
• Add just one ‘AddCars()’ function which returns list of ‘ICar’.

• If you execute the code, the output looks as below:

• That’s the flexibility we get with interfaces. I hope now you can relate the statement “Interfaces allow you to create a common set of methods that can be used across multiple classes, even if those classes have very different implementations.” with our Cars example.

You can download the whole code from here. I will continue this C# basics with more simple examples.

🙂

Recently, I got a deployment (ALM) specific query from my SharePoint colleague who was exploring Power Platform’s Canvas Apps.

Query:

• SharePoint team got 3 Sites (i.e., Dev/QA/Prod) and they also use 3 different Power Platform environments for Development, QA, and Production.
• On Development environment, a Canvas App was built connecting to ‘Dev’ SharePoint site.
• When the ‘Canvas App’ moved to QA and Production environments using Solution import, it must connect to the ‘QA’ and ‘Prod’ SharePoint sites.
• Following diagram depicts the topology.

Solution:

• It’s pretty a common scenario and one option would be post solution import to QA/Prod environments, reestablish the Connection reference manually. This option is time consuming and not intuitive.
• Other recommended option is “Data source environment variables”. We will see the ‘How’ part in next section.

Data source environment variables:

• As we know, Environment variables store the parameter keys and values, which then serve as input to various other application objects.
• Environment variables are now much simpler to work with and can store parameters required to connect to data.

In this article, lets see how to create and consume Data source environment variables in Canvas App.

Configure Data source environment variables:

Create Environment variables:

In this article, I am using SharePoint site to connect from Canvas App.

• Create a SharePoint site if not exists already and add a list using native ‘Issue Tracker’ template (You can also use any List of your choice).

• From Power Apps maker portal, connect to Dev environment and create a new solution.
• Create a new ‘Canvas App’ from the Solution.
• Now, from Canvas App, go to ‘File-> Settings’, enable the setting to Automatically create environment variables when adding data sources.

• Add a SharePoint data source and configure the Site and List.

• Once you add the ‘SharePoint’ data source, you would notice a banner message, indicates Environment Variables were auto created.

• Click on the ‘Manage them here’ will redirect you to the Solution where you can access the auto created ‘Environment Variables’.

• That’s all needed to create Environment Variables.

Configure Environment variables during Solution Export and Import:

Exporting Solution:

• Before exporting the solution, select one of the Environment variables and choose ‘Edit’ and select ‘Remove from this solution’.
  • This is step is important. You will not be prompted for new values during solution import if the environment variables already have either a default value or value present, if not chosen the ‘Remove from this solution‘.

• Repeat this step for other Environment variables.
• Export the solution.

Importing Solution:

• Select the target environment (I.e., QA in my case) and choose import the Solution.
• You will get following ‘Connections’ pane which will allow you to configure to the QA SharePoint site.

• You will be redirected Connections screen to establish connection to QA SharePoint site. Once you establish connection, it looks as below.

• Go back to Solution import process and map the new connection configured in above step.
• In the next step of import, system will ask you to provide values for the Environment variables (i.e., Site, List).

• You would not get above Connection reference and Environment Variables panes, if you have not chosen the ‘Remove from this solution‘ option.

This approach eliminates manual step of reestablishing connection post solution import to Target environment.

Important Points:

• ‘Data Source Environment’ variables doesn’t require querying environment variables via Dataverse connector or require premium licenses.
• The Environment variables can be unpacked and stored in source control using DevOps Power Platform tools.
• We can also use ‘Pre-existing’ data source Environment variables by creating a new ‘Environment Variables’ of ‘Data Type’ of ‘Data source’.
  • Use this option, if you don’t want auto creation of Environment Variables (i.e., By enabling the setting to Automatically create environment variables when adding data sources).

Refer docs for more details.

🙂

Using in-app notification feature (Preview) we can notify Users with in the Model-driven apps. In this article lets learn how to enable the feature and use the in-app notifications with different options step by step.

Enable In-app notifications feature:

• Connect to Power Apps Maker Portal.
• Open the ‘Model Driven App’ using ‘Edit in preview’ option.

• In the App Editor, select ‘Settings -> Upcoming’ and enable the In-app notifications (Preview) as below.

Create a Test User:

• To test the In-app notifications, create a new user account. This User acts as recipient of notification.
  • Note: If you already have more users in your environment, skip this step and use one of the existing Users as recipient.
• I’ve created an User named ‘Test User 1’ to send the notifications to.

• Open the Model driven app in another browser using the Test User account.

• Next copy the ‘Test User 1’ GUID by opening the User from ‘Advanced Find’. We will use this GUID while creating notification.

As we completed pre-requisites, its time to create notifications.

Creating our first notification:

• Notification features uses an OOB table called “appnotification”.
• We create a record in ‘appnotification’ table which turns out to be a notification for targeted User.
• Each notification row is meant for a single user, identified by the Owner column value.
• If a notification needs to be sent to multiple users, a record needs to be added for each recipient.
• The sender controls the recipient through the Owner column.

Following is code snippet is using ‘Client API’ to create a basic notification.

function showBasicNotification() {
    // GUID of User (i.e.,Test User 1 in my case) whom you want to send the Notification to.
    var systemuserid = "0758fd55-c2ca-ec11-a7b5-00224808dd66";
    var notificationRecord =
    {
        "title": "Welcome",
        "body": "Welcome to the world of app notifications!",
        "ownerid@odata.bind": "/systemusers(" + systemuserid + ")",
        "icontype": 100000000, // info
        "toasttype": 200000000 // timed
    }
    // Create notification record
    Xrm.WebApi.createRecord("appnotification", notificationRecord).
        then(
            function success(result) {
                console.log("notification created with ID: " + result.id);
            },
            function (error) {
                console.log(error.message);                
            }
        );
}

• Register the showBasicNotification() function on one of the form jscript events (i.e., On Load/On Save/Field_OnChange).
• For this blog post, I’ve registered script on ‘On Load’ event.

• Use Browser ‘DevTools’ (F12) to check the successful execution of function.

• Up on executing the script, end user (i.e., Test User 1) would get a notification as below.

Notification with Action(s):

• Using “data” tag we can create notifications that include actions, custom body definitions, and custom icons.
• Following code snippet contain 2 actions (i.e., 2 URLs to navigate to) in Notification.
  • ‘actions’ is an array.

function showNotificationWithMultipleActions() {
    // Notification with multiple actions as center dialog 
    var systemuserid = "0758fd55-c2ca-ec11-a7b5-00224808dd66";
    var notificationRecord =
    {
        "title": "Different Search Options",
        "body": "This is to inform you that you can use following search options",
        "ownerid@odata.bind": "/systemusers(" + systemuserid + ")",
        "icontype": 100000000, // info
        "data": JSON.stringify({
            "actions": [
                {
                    "title": "Bing",
                    "data": {
                        "url": "https://bing.com",
                        "navigationTarget": "dialog"
                    }
                },
                {
                    "title": "Google",
                    "data": {
                        "url": "https://google.com",
                        "navigationTarget": "dialog"
                    }
                }
            ]
        })
    }
    Xrm.WebApi.createRecord("appnotification", notificationRecord).
        then(
            function success(result) {
                console.log("notification created with multiple actions: " + result.id);
            },
            function (error) {
                console.log(error.message);
            }
        );
}

• Up on execution, End User gets a notification with 2 navigation actions as below.

Notification with a custom Title and Body:

• The data field supports overriding the Title and Body simple strings with a limited subset of markdown based.

• Below is the supported markdown.

Text Style	Markdown
Bold	**Bold**
Italic	_Italic_
Bullet list	- Item 1\r- Item 2\r- Item 3
Numbered list	1. Green\r2. Orange\r3. Blue
Hyperlinks	[Title](url)

• Newlines can be included with the body using \n\n\n\n.
• Following is a code sample using ‘Markdown’ to customize Title and Body.
  • Under ‘actions’ tag, url is pointing to an existing record.

function notificationWithCustomTitleAndBody() {
    var systemuserid = "0758fd55-c2ca-ec11-a7b5-00224808dd66";
    var notificationRecord =
    {
        "title": "Example of Custom Title and Body",
        "body": "Maria Campbell mentioned you in a post.",
        "ownerid@odata.bind": "/systemusers(" + systemuserid + ")",
        "icontype": 100000004, // mention (Displays @ symbol)
        "data": JSON.stringify({
            "title": "[Potential Prospect](?pagetype=entityrecord&etn=raj_prospect&id=48f5d750-cbca-ec11-a7b5-00224808dd66)",
            "body": "Here is a [Potential Prospect](?pagetype=entityrecord&etn=raj_prospect&id=48f5d750-cbca-ec11-a7b5-00224808dd66)",
            "actions": [
                {
                    "title": "View record",
                    "data": {
                        "url": "?pagetype=entityrecord&etn=raj_prospect&id=48f5d750-cbca-ec11-a7b5-00224808dd66"
                    }
                }
            ]
        })
    }
    Xrm.WebApi.createRecord("appnotification", notificationRecord).
        then(
            function success(result) {
                console.log("notification created with custom title and body: " + result.id);
            },
            function (error) {
                console.log(error.message);
            }
        );
}

• Up on execution End User receives notification as below.

Notification with a custom Icon:

• Within the notification, set iconType to Custom and in the body, include iconUrl with a value pointing to a web resource.
  • “icontype”: 100000005, // custom
  • “data”: “{ ‘iconUrl’: ‘/WebResources/cr245_AlertOn’}”
• The icon can be either an SVG or PNG file type.

• Following is the ‘notificationRecord’ object.

var notificationRecord = 
{
  "title": "Welcome",
  "body": "Welcome to the world of app notifications!",
  "ownerid@odata.bind": "/systemusers(" + systemuserid + ")",
  "icontype": 100000005, // custom
  "data": "{ 'iconUrl': '/WebResources/cr245_AlertOn'}"
}

• Notification with Custom icon looks as below.

Key points on Notification usage:

• If you don’t specify “ownerid@odata.bind” in ‘notificationRecord’ object, notification will go to the User who created Notification.
• Notification Polling:
  • In-app notifications uses polling to retrieve notifications periodically when the app is running.
  • New notification are retreived at start of the model-driven app and when a page navigation occurs as long as the last retreival is more than one minute ago.
  • If a user stays on a page for a long duration, new notifications will be retrieved.

• Notifications appear in the notification center until the recipient dismisses them or they expire. By default, a notification expires after 14 days but your administrator can override this setting
• You can change in-app notification behavior by setting Toast Type to one of the following values.

Toast Type	Behavior	Value
Timed	The notification appears for a brief duration (the default is four seconds) and then disappears.	200000000
Hidden	The notification appears only in the notification center and not as a toast notification.	200000001

• You can change the in-app notification icon by setting Icon Type to one of the following values.

Icon Type	Value	Image
Info	100000000
Success	100000001
Failure	100000002
Warning	100000003
Mention	100000004
Custom	100000005

🙂