Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Common Data Service – A Business Database!


Published on

In this session I tried to explain to SQL Community what is Common Data Service, it's a new Database or only a service to allow Power Users to create applications.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Common Data Service – A Business Database!

  1. 1. 25-05-2017
  2. 2. •Perguntar por slides •Colocar o logo do SQL Port •Colocar o título correto
  3. 3. About Me •14 years in Microsoft technologies • 6 years in Web, Desktop e Mobile • 8 working with CRMs •Head of Business Applications at Findmore (Nearshore Portugal) •Microsoft Partner company focused on providing CRM solutions, Sharepoint, Office 365 and Azure. Focus on Nearshore. •Business Solutions MVP 4.0 (Dynamics CRM)
  4. 4. Agenda •Business Application Platform •Dynamics 365 •What is? •Why the Common Data Service? •The Common Data Model •Data Types; Properties •Security •Integration •SDK •Future Common Data Service
  5. 5. Business Application Platform
  6. 6. Dynamics 365
  7. 7. What is? •Wouldn’t life be easier if everything just worked together? •Platform that enables customers to easily build the business apps and processes they need. •Brings together your business data in one place so you can focus on the things that matter: building apps, finding insights and automating your business processes •Going to be the backbone of future for business data. •Business application model and storage mechanism
  8. 8. What is? •Common Data Service (CDS) contains a Common Data Model (CDM) •Technologies •Azure infrastructure, an easy to provision, yet scalable data store (Service Fabric; Elastic SQL) •Integrations use M-engine (sits under power query), DIXF & OData under the hood! •M is the language used to move and transport data to and from CDS
  9. 9. Why the Common Data Service? •A common data model with standard entity schema and behavior •Set of standard entities deployed within every database •Integration with Microsoft Office for Excel and Outlook •SDK for professional development scenarios •Roles •Power Users – provides extensibility & enables point solutions via PowerApps, Flow, PowerBI •IT Admin – manage your company’s data and processes centrally. Security, roles, etc. applied consistently across all apps & services. •ISV App Developers – build your apps once with CDS and we’ll do the rest of the heavy lifting. •LOB App Developers – build your apss on top of all your company’s data in one place
  10. 10. Why the Common Data Service?
  11. 11. The Common Data Model
  12. 12. The Common Data Model •Provides a shared representation of the data that matters to your apps •Consists of standard, extensible, commonly used entities across business and productivity applications. •Applications can work against data without needing to explicitly know where that data is coming from •You can… •Create custom entities •Perform bulk data import export through the PowerApps portal •Leverage field groups to drive default PowerApps behavior •Use Standard Picklists & create your own •Analyse data in Power BI Perspectives for standard entities
  13. 13. The Common Data Model • Structured metadata • Entities are structured with data definition, behavior modeling and defaulting. • Rich data types • Address, Email, Currency, Auto-numbering. Modern types such as images, geographic location, Phone, Website • Data constructs • Support for modeling relationships, lookups, aggregates, containment etc. • System attributes (for concurency management, security, and audit trails) • RecordVersion, RecordId, DataPartition, CreatedByUser, CreatedByDateTime, ModifiedByUser, ModifiedByDateTime. • Entity and field level security can be configured per entity
  14. 14. The Common Data Model • Data validation for mandatory and unique field data and checking for invalid foreign key references • Data encryption at rest
  15. 15. Why use Standard entities? •Translations for standard entity names and fields into local languages •Field Groups to identify key fields for create, details and reporting scenarios •Predefined sample data •Security permission sets •Relationships to each other to support common business processes •Can be extended with custom fields to support •ISVs and other developers can all work against a common set of data
  16. 16. Entity field data types I Type Primitive Type Description Address Compound separate fields for first line, second line, city, state/province, ... AutoNumber String With prefix and an incrementing number. For example, “EXP001.” BigInteger BigInteger RecordId - included as a system field in every entity. cannot create Boolean Boolean True and False. Currency Compound two fields(decimal value; enumeration for the currency code). Date DateTime Only the Date portion of the DateTime type DateTime DateTime A date that is combined with a time of day with fractional seconds. Email String Email is stored as a string but is understood as a separate type Guid Guid A guid. Integer Integer An integer between -2,147,483,648 and 2,147,483,647.
  17. 17. Entity field data types II Type Primitive Type Description Lookup [Foreign key] The value matches the primary key in another table. Multiline Text String Multiple lines of text. Number Decimal can be stored 32 digits PersonName Compound given name (first name), middle name, and surname (last name). Phone String Phone is stored as a string but is understood as a separate type Picklist Integer The integer serves as a reference into one of the standard picklists. Quantity Quantity A decimal value. Text String One line of text. Url String Url is stored as a string but is understood as a separate type
  18. 18. Entity field properties Property Applies To Description Default value Text The default value of the Text field. Max length Text The maximum number of characters in a text field. Prefix Number Sequence The prefix that is used for the number sequence. Picklist Picklist The option set type of the field. Required All A value is required for the field. Searchable All The data can be searched. Unique All Values for the field must be unique across the entity.
  19. 19. Naming Conventions •Entity names are singular •Examples: Tenant, Family, SalesOrder. •Entity ID names are created by appending “Id” to the entity name •Examples: WorkerId, CaseId, FamilyId. •Lookup fields are named with the entity name of the entity that they are related to
  20. 20. Entity relationships and lookup fields •Referential integrity •Cascading delete •Associated rows in the referencing entity are deleted. •Restricted delete •Cannot delete a row in the referenced entity if it has associated rows in the referencing entity. • Self => Supported • One-to-one => Not Supported • One-to-many => Supported • Many-to-many => Not Supported
  21. 21. Database Security •There are two modes in which the Common Data Service can run: •Open mode – the data stored in the common data service is open to all users. Everyone will always have the needed permissions to use any app. •Restricted mode – Grant specific data permissions to users by using the admin center. When running in, you will need to configure the role- based security.
  22. 22. Security Model •Data in the Common Data Service can be secured at several levels: •Database level – Admins can define which users can perform all administrative operations in the Common Data Service. •Entity level – Admins can define which users have access to entities, and what actions those users can take on those entities •Record level – Admins can use policies to define which records a user has access to in a given entity.
  23. 23. User Roles •User role are assigned to users or user groups within your organization to provide them access to a collection of entities. •The entities that a role provides access to are determined by the permission sets that the role includes. •There are two special roles that are provided by the Common Data Service for your convenience. •Database Owner – provides access to all entities in your database, even as new custom entities are added. assign users to roles, and define the permissions for those roles. •Organization User – assigned to all users in your organization automatically. In Restricted mode, everyone will need to be provided access to the entities that the PowerApp is using. •A user can be assigned multiple roles to allow access to different sets of
  24. 24. Permission Sets •The standard entities have been grouped, and each group has two permission sets : •View – allows read-only access to the data within the entity •Maintain – allows read, create, update and delete operations within the entity. •A permission set is comprised of a list of entities and the level of access granted for each entity. •Create, read, update, and delete permissions can be granted to any entity •To grant access to a custom entity you must provide an access level under a permission set.
  25. 25. Policies - Record Level Sercurity (Preview) •Determine the records that a user has access to within an entity •The policy allows you to limit the data returned to the user. A policy restricts access based on the value of a field within the record. •Policies can be defined to only return values: •With a given picklist value •Where the current user of the application matches the user stored in the record •Separate policies can be defined for each data operation: Create, Read, Update, and Delete •Security configuration can also be done in code via the Common Data Service SDK
  26. 26. Data Import Export •Standard and Custom entities •Data import feature that allows hundreds of thousands of records to be imported and exported efficiently. •Exporting template files (Excel spreadsheets or CSV delimited) for entities that match the schema of the target entity and can have a subset of the entity fields •The template designer let’s you pick fields that you care about and quickly add required fields. •Quickly and easily import data from your existing systems. •Rapidly establishes trusted connections for IT-managed tenants. •The trusted connections continually synchronize the data between your existing systems and your platform solutions.
  27. 27. Integration •Productivity add-ins to access your data from Microsoft Excel and Outlook. •Your solutions can connect information from productivity platforms with data from business applications. •Connects through standard interfaces, such as the Microsoft Graph •Maps entities to the productivity platform objects to enable the join relationships with business data.
  28. 28. Excel Add-in •All standard and custom entities can be interactively viewed and edited in Excel •Excel Add-in that provides data entry with data-type specific assistance for picklists, dates and lookups
  29. 29. Outlook Add-in •Data from the Common Data Service related to the people in emails and meetings •In this first release, the Outlook Add-in only looks for related data in a few entities such as Cases •End-users can manage the relevant data in the CDS without your LOB app or IT department needing to lift a finger
  30. 30. Microsoft Dynamics 365 data integration •The Prospect to Cash data integration feature enables a basic flow of account data and other entity data to enable a prospect-to-cash scenario. •The data integration feature is available to customers who have at least one Dynamics 365 product
  31. 31. How to build and manage apps? • For the low-code/novice app creator • PowerApps - Drag and drop to create your apps on data from the CDS • Power-up your Powerapps by building complex logic with the C# SDK and host it in an Azure Function • For the professional developer • Rich C# SDK – enables you to build complex web apps or rich client applications. • Environments group features together in CDS including: • A collection of tables and table relationships • Publishing Power Apps • Integration and mapping tools connected to Dynamics 365
  32. 32. Example of Business Applications •Dynamics 365 for Retail •Dynamics 365 for Talent
  33. 33. SDK I •Allows create, read, update, delete (CRUD) and even query your business data residing in the Common Data Service •The client and the server tiers communicate through JSON documents that describe the operations required •Is viable create applications by building the JSON documents with string operations and using standard HTTP protocols to transmit them over the wire to the Common Data System endpoints •Advantage of API is a higher abstraction level, offering a strong type system to help you at design time rather than running the risk of failing at runtime •It is useful to think of these SDKs as domain-specific languages (DSLs) implemented in their host languages. •In the terminology of the SDK, tables are called entitysets, as opposed to entities. Entities are in turn the records in the entitysets.
  34. 34. SDK II •Authentication of the user is against Azure Active Directory •Almost all the methods provided by the SDK are available as asynchronous methods •The types representing entitysets are merely C# classes without much fanfare (POCOs) •In the SDK the concept of transactions does not exist: •We have to add all the entities to an executor. The executor is then responsible for managing the transaction in the most effective manner •The server layer will deserialize the entities, start a transaction, insert the records, and commit the transaction
  35. 35. SDK – Query Data I •Almost all the methods provided by the SDK are available as asynchronous methods •The types representing entitysetsare merely C# classes without much fanfare (POCOs) •No option for specifying "all fields", since misuse caused performance issues in other systems var query = client.GetRelationalEntitySet<ProductCategory>() .CreateQueryBuilder() .Where(pc => pc.Name == "Surface" || pc.Name == "Phone") .Project(pc => pc.SelectField(f => f.CategoryId).SelectField(f => f.Name));
  36. 36. SDK – Query Data II •Joining data from multiple entitysets •Joins – entitysets carry with them a lot of metadata that describes the relationships among them, you typically don't have to specify the fields that are used to do the join in the query. •Zips •If you haven't modeled any relationships. For this purpose, you can use the Zip clause, where you specify both the joined entityset and the relationship that defines the join. •Grouping data •Using aggregates •This approach is preferable to manual aggregation, because the data isn't transported over the wire, and the aggregations are done very quickly. •Paging •Able to fetch a certain number of records after several records have been skipped. To achieve this result, you can add Take and Skip clauses to the query.
  37. 37. Generally Available • Improved app from data generation on standard and custom entities with field groups • Multi-field lookups • Editable data import/export entity field mappings • Ability to export data import/export templates • Multi-sheet Excel import • Simplified address type, complex types for Quantity, Person name, GUID, Date • Central place to view entity relationships
  38. 38. Generally Available • Simplified primary key definition • Searchable fields allow for indexed searches • Entity data explorer in creator portal • Null support • Default value support for simple data types • Manage Custom Picklists
  39. 39. PowerBI (Preview) •Power Apps Common Data Service (CDS) connector to Power BI desktop •This means your data model and all the data in it is natively accessible in Power BI Desktop •Secured with the roles and policies IT Pros have defined in CDS •Reports reflect real time data •There’s no need to schedule a refresh in Power BI. When the data is updated in CDS, changes are reflected in reports •Power BI is aware of rich data types and relationships defined in CDS •These types are recognized by Power BI as first class data types. •For an example, when you report using an address field, Power BI shows a map as a default visualization. •Entities are presented by subject areas (perspectives) •While CDS contains a rich set of entities representing many business areas •Entities are organized into a set of ready-made subject areas called Perspectives. A perspective offers a “view into data” from a reporting point of view.
  40. 40. Future I •Common Data Model will grow from 70+ entities today to 300+ entities in the next quarter •Security •Column level security •Add the ability for IT Pros to secure data based on even more advanced business artifacts and concepts such as hierarchies, regions and business units. •Multiple Dynamics 365 applications and offerings that are built on this Common Data Service. These apps build on the CDS, so the data that’s used by those apps are available for you to build your own apps against. •Make PowerApps + CDS even simpler, by introducing more powerful out-of- the-box forms that will automatically configure based on entity metadata and relationships •Improved import/export capabilities so you can choose which entities and
  41. 41. Future II •With Dynamics 365 for Sales or Operations, or even Azure Active Directory and Office 365, we’re making it so that your data just shows up in the Common Data Service. •Working with the Office 365 team so that business processes and apps can use productivity artifacts like calendar events and tasks natively in their apps •Working very closely with the Microsoft Graph team so that the data we bring together in CDS is exposed via the Graph for apps that are already built using the Graph REST APIs or SDKs •Working with partners like Microsoft StaffHub to automatically integrate data from your Dynamics services to enhance users’ StaffHub experiences
  42. 42. Future III
  43. 43. Pricing
  44. 44. Resources •PowerApps Blog • •Entity Reference Guide • BC13AD8DB6E2/CDMEntityReference.docx •Preview Program •
  45. 45. Contacts • • • •@azevedo_pedro
  46. 46. Questions?
  47. 47. CONTACTS @azevedo_pedro