0% found this document useful (0 votes)
3 views

Module 2

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views

Module 2

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

M2 – Core Components of Microsoft

Dataverse

Difference between Databases and Dataverse


 Extra things Dataverse can do:
1. Azure Active Directory for identity services and triple A;
authentication, authorization, and accounting.
2. Logic wise, Dataverse can apply business rules at the data level
so that those rules are applied for all users everywhere.
3. Data tools include the data modeling and transformation
functions which are sale as with Power BI.
4. Storage is the Azure Cloud. So all the protection of the storage
that you would use for any of your other Azure applications also
applies to Dataverse protection.
5. And finally integration. Dataverse is integrated everywhere into
many of the Microsoft 365 apps and a lot of other functions. So it
actually enables users to have a wider variety of tools available
to them than your average database manager. And those tools
are even relatively accessible compared to some other database
environments.

 When anyone creates an app or a flow within Microsoft


teams or even installs one, an app, Teams creates a separate
instance of the Dataverse called Dataverse for Teams. It's a
separate environment designed exclusively for the use of the
team and its members.
 It's a standard environment, but it has no connection to the
outside.
Each database instance in the Dataverse can hold up to four terabytes of
storage although it's possible to purchase additional storage if you have
more data than that.

Tables, Columns and Relationships:


 A Dataverse database consists of elements called tables with each
table having a set of columns.
 The Common Data Service is now the Microsoft Dataverse.
 Tables are tables, columns are columns.
 Relationships are the links between tables in an app when
the app contains multiple data types stored in different
tables.
 You can create your own tables and add columns to an existing
table.
 Types of data in columns – text, numerical, choice etc.
 Selecting the Relationships tab displays another list of all the
relationships between elements in different tables.
 Types of relationships –
1. One-to-many relationship is between one element that
connects to many elements for example one invoice and a
number of products that are being ordered. This relationship
can also be called a parent/child relationship or 1:N
relationship.
2. The opposite is Many-to-one relationship in which many
elements are connected to one, for example it could be an
invoice table containing customer information. Each customer
is the one which may have many invoices, but every invoice is
only associated with one customer.
3. Many-to-many has many records in one table are associated
with many records in another. This is known as a peer
relationship between the tables.
 It's possible to create new relationships of any of the types.
Business Logic:
 Any modifications that developers make to the database are called
solutions, and it's possible for the developer to save the solutions as
a single file, enabling them to implement those same changes on
another system, another tenancy, another database instance.
 There are two types of solutions –
1. An unmanaged solution is intended for a development
environment in which changes are regularly being made to the
database. Developers can then export an unmanaged solution as
either managed or unmanaged.
When you import an unmanaged solution into an environment,
the changes that are saved in that solution are applied.
If the developer subsequently deletes that unmanaged solution,
the file disappears but the changes that have been made are
retained in the database.
2. A managed solution on the other hand is intended more for a test
or a production environment. When developers save a managed
solution, they can apply it to another system but they cannot edit
the components in the managed solution directly. In other words,
once you've saved a managed solution, it's intended for an
environment in which the changes made to the database are set.
If the developer wants to make further changes, they must save
the managed solution as an unmanaged solution and then they
could make changes to it. When you delete a managed solution
that's been imported into a database, not only the solution file
but all of the changes made to the database are deleted as well.

 As with everything to do with the Microsoft Dataverse, it's possible


to create new solutions. The actions you create in business rules are
based on standard verbs supplied with the business rule system.
 Verbs such as create, update, and delete the standard kind of verbs
you would expect in working with database records.
 However, it's possible to create custom actions, also called custom
process actions, in which you're creating new verbs that consist of
multiple steps such as approve, escalate, or convert. And by
creating a custom action, you can define what a verb such as
approve consists of in listing its various steps. T
 wo terms involved with business logic that you don't want to
confuse are work flows and data flows.
1. Real-time workflows are a means of automating processes in
tables that do not require user interaction. Workflows are
organized into stages much like a business process and each
stage consists of a series of steps. The steps can cause the
workflow to create, update, and assign table rows as well as
launch other workflows.
There is aside from the real-time workflow, there's another
kind called the background workflow which is run by Power
Automate.
2. Dataflows, in contrast, are a feature of Power Apps that enable
data to come from multiple sources and be combined into one
Dataverse instance.

Connectors:
 Connectors are a Power Platform component that enables Power
Apps and Power Automate to interact with outside data sources,
including applications, services, and local data files.
 It can be either on a read only basis or by reading and writing.
 There are over 200 connectors available with Power Platform tools.
 For applications and services that do not have connectors created
for them, it's possible for developers to create their own custom
connectors.
 A connector is a proxy wrapper, which is a way of saying it's an
intermediary between an application programming interface
provided by the data source outside of Power Platform and the tool
within power platform itself that you're working with.
 Many applications and cloud services have the necessary APIs that
have made it possible to create connectors for them. Not all of
them, however, do. And in that case, it's possible to create customs.
 The connector in its role as an intermediary is responsible for
authenticating to the outside application or service and then
provides the data it can access to Power Apps or Power Automate.
 When you look at the Power Apps portal and select the Connections
page, you see a list of the connections that are currently in use in
the environment that's selected. If you select one of these
connections, you'll see a detail page that lists all the apps in this
case that are utilizing that connection.
 So you could have a single instance of a notifications connection
and use it in multiple apps and flows within the environment.

Triggers:
 Triggers are the means by which Power Automate flows are
launched.
 There are several different types of triggers you could use in Power
Automate –
1. A schedule-based trigger launches the flow at a specified date
and time.
2. Event-based trigger launches the flow when the user performs a
specific task.
3. A manual trigger is one where the user launches the flow by
clicking or tapping a button.
4. Connector based triggers which are integrated into many
connectors so that the connector can actually determine when a
flow should be launched.
 Flow Trigger types –
1. In polling trigger, the connector accesses the data source at
scheduled intervals and checks for any new data that has
arrived. If the conditions met in the selected trigger occur, then
the flow is launched. But it's up to the connector to repeatedly
access the data source and monitor its activities.
2. Push trigger is one in which the server endpoint listens for
notifications that a specific event has occurred on an outside
application or service.

Licencing Options for Connectors:


1. A standard connector is free with the Power Apps and Power
Automate tools and available to all licensees regardless of how they
acquired Power Apps or Power Automate.
2. The premium connectors are available only to licensed users of the
standalone versions of Power Apps and Power Automate as well as
Dynamics 365 users. It's important to remember that Power Apps
and all the Power Platform tools started out as individual products,
and they're still available as such. A user can go and purchase a
Power Apps license and just work with that without owning the
entire Power Platform collection of tools.
The premium connectors are more elaborate applications and
services. These are generally more sophisticated applications and
services and that's why they are charging a premium price for the
premium connectors.
3. Custom connectors let you create your own connectors depending
on what the data source has available to you. When you click the
new custom connector button, you can create a connector from a
blank, from an Azure service, from an open API file, postman
collection and GitHub.
These are all options that may or may not be available depending
on the data source you're trying to connect to.
In some cases, a data source might have no capability for
connecting to outside services and it may be necessary to start from
scratch if you're really going to create a custom connector for it,
which will require a goodly amount of time and expertise.
In some others, the data source has the necessary APIs but there
just is no connector in the Microsoft product. So you simply have to
create a new custom connector to use that API, such as an open API
file.
When you create a custom connector, you run through a wizard that
has four screens.
o The first one provides general information about the data
source you're trying to connect to and specifies the location of
it, the host, the URL.
o The second one is security and where we talk about the type
of authentication is going to be used to access the data source
as well as the credentials.
o The third screen is a definition in which you specify actions,
triggers, references, and policies that apply to this new
connector.
o And finally, there is a test screen where you can test the
operation of your custom connector before going into a live
production environment.

You might also like