Microsoft Dataverse – datový základ pro aplikace, procesy a AI

Po dvou úvodních článcích, ve kterých jsme si představili základní stavební kameny Power Platform a související svět Dynamics 365, nám zbývá doplnit ještě jednu důležitou část. Než začneme stavět procesy využívající AI, potřebujeme pochopit prostředí, ve kterém budou pracovat s podnikovými daty.

Dnes se proto podíváme na Microsoft Dataverse, který můžeme považovat za srdce datové vrstvy Power Platform.

Jak už název napovídá, budeme se věnovat datům. Hned na začátku je ale potřeba pochopit jednu zásadní věc: Dataverse nabízí mnohem více než jejich ukládání.

Microsoft Dataverse je cloudová datová platforma pro ukládání a správu podnikových dat. Vedle tabulek poskytuje také zabezpečení, metadata a obchodní logiku, které mohou aplikace společně využívat.

Definice je to pěkná, ale při prvním setkání může působit trochu abstraktně. Pojďme si proto jednotlivé schopnosti postupně vysvětlit.

Začneme u dat. Potom se podíváme na zabezpečení, události, obchodní logiku, API a integrace. Na závěr propojíme svět provozních aplikací s analytickým zpracováním dat.

Data: kde a jak s nimi pracujeme?

Dataverse nabízí několik přístupů k práci s daty. Pro tento úvod si představíme standardní, elastické a virtuální tabulky.

Standardní tabulky budou pro většinu běžných podnikových aplikací výchozím bodem. Hodí se pro evidenci zákazníků, obchodních příležitostí nebo servisních požadavků — tedy pro běžná transakční data.

Elastické tabulky využívají Azure Cosmos DB a jsou navržené pro velké objemy dat a vysoký počet čtení a zápisů. Příkladem mohou být data ze senzorů nebo velké množství provozních záznamů. Mají ale odlišné transakční chování a nepodporují všechny funkce standardních tabulek. Volíme je proto podle konkrétních požadavků řešení.

Virtuální tabulky nám umožňují zpřístupnit data, která zůstávají v jiném systému. V aplikaci je můžeme zobrazovat jako tabulky Dataverse, aniž bychom je museli kopírovat do jeho vlastního úložiště. Dostupné operace a omezení závisejí také na použitém poskytovateli a zdrojovém systému.

Setkáme se také s tabulkami aktivit, které slouží například pro úkoly, schůzky nebo telefonní hovory. Ty představují další specializaci datového modelu, kterou si můžeme podrobněji představit jindy.

Pro začátek je důležité zapamatovat si, že výběr tabulky ovlivňuje možnosti celého řešení.

Zabezpečení: kdo může s daty pracovat?

Teď už víme, jak můžeme v Dataverse pracovat s daty. Další otázkou je, kdo k nim smí přistupovat a co s nimi může dělat.

Představme si vlastní interní aplikaci pro nákupní požadavky. Zaměstnanci v ní žádají o nové vybavení, vedoucí kontrolují požadavky svého oddělení a centrální nákup potřebuje přehled napříč firmou.

Každý z nich pracuje se stejnou aplikací, ale potřebuje jiný přístup k datům.

Pomocí bezpečnostních rolí určujeme, jaké operace může uživatel provádět — například číst, vytvářet, upravovat nebo mazat záznamy. U tabulek vlastněných uživatelem nebo týmem můžeme pro jednotlivé operace nastavit také rozsah přístupu: vlastní záznamy, záznamy příslušné business unit, její podřízené jednotky nebo celou organizaci. Čtení a úpravy přitom mohou mít odlišný rozsah.

Právě zde přicházejí na řadu business units, tedy organizační jednotky Dataverse. Pomáhají vytvářet hranice přístupu k datům. Mohou odpovídat například pobočkám, divizím nebo oddělením firmy a můžeme je uspořádat do hierarchie. Nemusí ale přesně kopírovat organizační schéma — jejich strukturu navrhujeme podle potřeb zabezpečení. Samotné zařazení uživatele do jednotky přístup nezaručuje; rozhodují také jeho role a další udělená oprávnění.

V naší nákupní aplikaci tak můžeme navrhnout například následující rozdělení:

• Zaměstnanec vidí své vlastní požadavky.
• Vedoucí pražské pobočky vidí požadavky své pobočky.
• Regionální vedoucí vidí požadavky své jednotky i podřízených poboček.
• Centrální nákup má přehled o požadavcích celé firmy.

Stejný přístup můžeme využít při evidenci interních projektů, provozních incidentů nebo žádostí o školení. Podstatné je, které záznamy jednotliví lidé potřebují ke své práci.

Spolupráci napříč odděleními lze řešit také pomocí týmů a sdílení konkrétních záznamů. Pro složitější struktury nabízí Dataverse možnost přidělovat uživateli role z více business units, pokud je zapnutá příslušná funkce pro vlastnictví záznamů napříč jednotkami.

Oprávnění z rolí se sčítají. Pokud jedna role dovolí číst data celé firmy, užší role tento přístup neomezí. Při návrhu proto potřebujeme zohlednit všechna oprávnění, která uživatel získává přímo i prostřednictvím týmů.

U podporovaných sloupců lze samostatně omezit přístup k citlivým údajům. Uživatel tedy může mít přístup k záznamu, aniž by automaticky viděl všechny jeho hodnoty.

Právě tady začíná být dobře vidět hodnota společné platformy. Zabezpečení řešíme přímo na úrovni dat. Každá další aplikace nad těmito daty tak může vycházet z již nastavených oprávnění.

Je přitom důležité rozlišovat mezi skrytím údaje na obrazovce a skutečným omezením přístupu. Pokud údaj pouze nezobrazíme ve formuláři, ještě jsme tím nevyřešili jeho zabezpečení.

Události: co se má stát, když se data změní?

Podívejme se teď na jiný business scénář: firmu, která prodává a servisuje technologická zařízení. Zákazník nahlásí poruchu a v systému vznikne servisní požadavek.

Jeho uložením proces většinou nekončí. Naopak právě začíná.

Potřebujeme upozornit odpovědného pracovníka, zahájit přiřazení požadavku nebo předat informace dalšímu systému.

Dataverse umožňuje reagovat na operace nad daty prostřednictvím událostního mechanismu. V Power Automate můžeme například vytvořit tok, který se spustí po vytvoření, úpravě nebo odstranění záznamu ve vybrané tabulce.

V našem příkladu může po založení požadavku začít automatizace, která upozorní servisní tým. Při změně stavu na „Vyřešeno“ může navázat další tok, který připraví zprávu zákazníkovi.

Pro pokročilejší scénáře nabízí Dataverse také plug-iny, webhooky a integrace s Azure. Ty umožňují rozšířit chování platformy a reagovat na podporované události vlastním způsobem.

Prozatím si stačí zapamatovat jednoduchý princip: změna dat může být impulzem pro další krok procesu.

Obchodní logika: jaká pravidla musí platit?

Událost nám říká, že se něco stalo. Obchodní logika určuje, jak se má řešení zachovat a jaké podmínky musí splnit.

Představme si pravidlo, že servisní požadavek nesmíme uzavřít bez popisu řešení.

Můžeme vytvořit kontrolu ve formuláři. Co když ale požadavek upravuje jiná aplikace nebo integrace? Pokud má pravidlo platit při každém relevantním zápisu, potřebujeme jej vynutit také na serveru.

Dataverse nabízí business rules, pomocí kterých můžeme vytvářet jednodušší podmínky a validace bez psaní kódu. Záleží ale na nastaveném rozsahu: některá pravidla pracují pouze ve formuláři, jiná mohou běžet také na serveru.

Složitější obchodní logiku lze implementovat pomocí plug-inů. Ty mohou například při podporované operaci ověřit podmínky a při jejich nesplnění zápis odmítnout.

Při návrhu proto potřebujeme rozhodnout, která logika pomáhá uživateli při práci s aplikací, která chrání správnost dat a která řídí navazující proces.

Například kontrola podmínek uzavření požadavku patří k pravidlům zápisu. Odeslání následného upozornění už můžeme řešit navazující automatizací.

API: jak s Dataverse komunikují jiné aplikace?

Dosud jsme se na Dataverse dívali hlavně z pohledu Power Platform. Ve firmě ale obvykle máme také vlastní aplikace, externí služby nebo systémy jiných dodavatelů.

Pro jejich připojení nabízí Dataverse Web API. Přes toto rozhraní mohou aplikace načítat, vytvářet, upravovat a odstraňovat záznamy nebo vyvolávat další podporované operace. Vývojáři mohou využít také SDK pro .NET.

V našem příkladu může externí aplikace založit nový servisní požadavek nebo načíst jeho aktuální stav.

Taková operace probíhá pod konkrétní identitou a podléhá jejím oprávněním. Proto je důležité vědět, pod jakým účtem integrace pracuje a k jakým datům má tento účet přístup.

Pokud jsme potřebnou kontrolu implementovali v příslušné serverové logice, může se uplatnit také při zápisu přes API. Právě proto jsme v předchozí části rozlišovali pravidla formuláře a pravidla vynucovaná platformou.

Integrace: jak Dataverse zapadá do firmy?

API představuje rozhraní pro komunikaci. Integrace už řeší celý tok informací mezi systémy. Dataverse nám pro tento účel nabízí několik cest — od automatizací v Power Platform přes předávání událostí externím službám až po zpřístupnění dat pro analytiku.

Začněme u triggerů v Power Automate, které jsme zmínili v části o událostech. Vytvoření, úprava nebo odstranění záznamu může spustit tok, který naváže dalšími kroky a pomocí konektorů komunikuje s jinými systémy. V interní nákupní aplikaci tak může nový požadavek zahájit schvalování a po schválení předat informace do dalšího systému.

Pokud potřebujeme reagovat vlastní službou, můžeme využít webhook. Dataverse při zaregistrované události odešle HTTP požadavek s informacemi o operaci na určený endpoint. Příjemcem může být například naše služba v Azure Functions, která zahájí další zpracování.

Další možností je napojení na Azure Service Bus. Dataverse dokáže předávat kontext zaregistrovaných událostí do této služby, odkud jej mohou zpracovávat další aplikace. Fronty a témata umožňují oddělit odeslání zprávy od jejího následného zpracování. To se hodí například při předávání schválených požadavků do podnikového systému, který nemusí být schopný každou zprávu zpracovat okamžitě.

Webhook představuje přímé volání služby. Service Bus přidává vrstvu pro asynchronní předávání a zpracování zpráv. Volba závisí na zátěži, dostupnosti navazujících systémů a požadavcích na spolehlivost.

Při návrhu každé integrace potřebujeme vědět, který systém je hlavním zdrojem údaje, jak rychle se musí změny předávat a co uděláme, pokud zpracování selže. U zpráv je také potřeba počítat s možností opakovaného doručení, aby stejný požadavek nevytvořil například dvě objednávky.

Microsoft Fabric: od provozních dat k analytice

Vedle předávání jednotlivých událostí potřebujeme často pracovat také s větším množstvím dat a vyhodnocovat je v širších souvislostech. Tady se dostáváme k propojení Dataverse s Microsoft Fabric.

Pomocí funkce Link to Microsoft Fabric můžeme data z Dataverse zpřístupnit ve Fabric prostřednictvím OneLake shortcuts. Dataverse pro tento účel udržuje analytickou repliku dat ve formátu Delta Parquet a její aktualizace se promítají do propojeného lakehouse. Nemusíme tedy od začátku stavět vlastní exportní a ETL proces. Nad těmito daty pak můžeme vytvářet analytické modely a reporty například v Power BI.

Právě toto propojení představuje cestu od provozního přístupu k analytickému přístupu.

Dataverse tak může podporovat každodenní chod aplikace, zatímco ve Fabric připravujeme analytický pohled nad jejími daty. Nejde o změnu samotného Dataverse na OLAP databázi, ale o propojení provozní a analytické vrstvy.

Na stejné nákupní požadavky se díky tomu můžeme dívat ze dvou perspektiv. V aplikaci řešíme, co je potřeba právě teď schválit. V analytice zjišťujeme, kde vznikají prodlevy, jak se mění náklady a co můžeme ve fungování firmy zlepšit.

Dataverse v kontextu celé platformy

V dnešním článku jsme si ukázali, že při návrhu řešení v Power Platform potřebujeme chápat Dataverse v širších souvislostech. Ukládání dat je pouze začátek. Stejně důležité je, kdo s nimi může pracovat, jaká pravidla při jejich změně platí a jak na ně navazují další procesy a systémy.

Právě propojení dat, zabezpečení, obchodní logiky a integrací dává Dataverse jeho hodnotu. Nad společným základem můžeme vytvářet aplikace, automatizovat firemní procesy a zpřístupňovat provozní data pro analytiku. Rozhodnutí, která v této vrstvě uděláme, pak ovlivňují celé řešení — jeho možnosti, správu i další rozvoj.

Proto považuji pochopení Dataverse za důležitý krok před zapojením AI. Potřebujeme vědět, odkud informace přicházejí, kdo k nim má přístup a za jakých podmínek lze provádět další kroky procesu.

V příštím článku už se podíváme na možnosti AI, které nám Power Platform a navazující ekosystém Microsoftu nabízejí. Představíme si Copilot Studio, prozkoumáme AI možnosti samotného Dataverse a zasadíme je do širšího kontextu. Podíváme se také na Work IQ a jeho roli při poskytování pracovního kontextu z Microsoft 365 a připojených systémů AI agentům.

Cílem bude pochopit, jak do sebe jednotlivé části zapadají a jak je můžeme využít při návrhu konkrétních podnikových řešení.