Gegevensintegratiepatronen voor Microsoft Cloud for Sustainability

Het gegevensmodel vormt de basis voor de Microsoft Cloud for Sustainability. Afhankelijk van het volwassenheidsniveau van het gegevensbezit kan de oplossing integratie met andere systemen vereisen. Het kiezen van het juiste patroon is cruciaal voor een succesvolle implementatie.

Dit artikel introduceert integratiepatronen, tools en beslissingsfactoren, terwijl eenmalige gegevensopname of migratierichtlijnen worden behandeld in Gegevensmigratiestrategie voor Microsoft Sustainability Manager.

De behoefte aan integratie

In de snelle zakelijke omgeving van vandaag staan organisaties voor veel uitdagingen bij het beheren en integreren van hun systemen en gegevens. Een van de grootste obstakels is de behoefte aan integratie tussen verschillende duurzaamheidsoplossingen, wat tijdrovend, complex en kostbaar kan zijn.

De opkomst van sectorspecifieke Microsoft Cloud-oplossingen biedt echter een veelbelovende oplossing voor dit probleem. Door een gemeenschappelijk gegevensmodel te gebruiken dat wordt gedeeld door meerdere oplossingen van derden, kan de behoefte aan integratie aanzienlijk worden verminderd of zelfs helemaal worden geëlimineerd. Ga voor details op acceptatieniveau naar Volwassenheidsniveaus van gegevensbezit. Integraties kunnen echter nog steeds vereist zijn voor de volgende scenario's:

• Het proces omvat meerdere systemen en gegevens moeten van het ene systeem naar het andere worden gesynchroniseerd.
• Gegevens worden gedeeld of uitgewisseld tussen systemen wanneer dat nodig is voor uitstootberekeningen.
• Gegevens worden gedeeld of uitgewisseld tussen systemen, zodat acties die in het ene systeem plaatsvinden, worden weerspiegeld in het andere systeem.
• Geaggregeerde gegevens van een systeem met een gedetailleerd gegevensniveau worden uitgewisseld met een systeem met een gegevensweergave op een hoger niveau.

Hoe u het juiste integratiepatroon selecteert

Er zijn veel technische opties beschikbaar voor integratieontwikkeling, elk met zijn eigen voor- en nadelen. Om het juiste integratie-uitbreidingspatroon te identificeren, kunt u de volgende factoren in overweging nemen en deze wegen over de opties:

Beslissingsfactor	Omschrijving
Gegevenstypen en -indelingen	Wat is het type en de indeling van gegevens die worden geïntegreerd?
Volatiliteit van gegevens	Veranderen de gegevens die moeten worden gesynchroniseerd vaak?
Gegevensvolume	Wat is het volume van de gegevenswijziging die moet worden gesynchroniseerd?
Beschikbaarheid van gegevens	Wanneer wilt u dat de gegevens gereed zijn, van bron tot doel? Zijn deze in realtime nodig of hoeft u alleen maar alle gegevens aan het einde van de dag te verzamelen en in een geplande batch naar het doel te verzenden?
Servicebescherming en aanvraagbeperking	Gelden er limieten op basis van tijdvenster, gelijktijdigheid en rechten?
Vereist niveau van gegevenstransformatie	Is er een vereiste om de brongegevens te converteren of samen te voegen naar het doel?
Triggers en triggeracties	Welke actietriggers verzenden gegevens van de bron naar het doel? Welke specifieke acties moeten worden geautomatiseerd nadat de gegevens bij het doel zijn aangekomen?
Foutafhandeling	Wordt er toezicht gehouden om eventuele problemen met de interfaces op te sporen?
Schaalbaarheid	Hoe gaat u om met de verwachte transactievolumes op de huidige, korte en lange termijn?
Registratiesysteem	Welk systeem is het registratiesysteem of de eigenaar van de informatie?
Richting van gegevensstroom	Moet het doelsysteem de gegevens ophalen of worden deze verzonden door het bronsysteem?

Op basis van deze factoren kunt u het integratiepatroon identificeren en ook de juiste tool of technologie kiezen voor implementatie.

Integratiepatronen

Er zijn verschillende patronen die kunnen worden gebruikt bij het integreren met Dataverse. Elk patroon vertegenwoordigt een vorm die kan worden gerealiseerd met behulp van een of meer technologieën. De realisatie van deze patronen met technologie wordt in de volgende paragrafen uitgelegd.

Realtime of synchrone integratie

Realtime integratie is nodig wanneer het bronsysteem (Toepassing-A) wat informatie verzendt en een onmiddellijke respons van het doelsysteem (Toepassing-B) nodig heeft, zodat het enkele vervolgacties kan uitvoeren.

Dit patroon kan worden geïmplementeerd met deze technologieopties:

Notitie

Inkomend verwijst naar inkomende serviceoproepen naar Dataverse, terwijl uitgaand verwijst naar uitgaande serviceoproepen van Dataverse naar andere systemen.

Technologieoptie	Inkomend/Uitgaand	Doel	Wanneer gebruiken
Dataverse API	Inkomend (push)	OData v4-implementatie om CRUD-bewerkingen te bieden met behulp van een standaardset interfaces, waardoor een interface wordt geboden die openstaat voor een brede technologische doelgroep.	Meestal voor transactionele app-integratie wanneer discrete CRUD-bewerkingen vereist zijn. Kan ook worden gebruikt voor elke aangepaste integratie, maar brengt complexiteit met zich mee met betrekking tot aanvraagbeperking, parallellisme en logica voor opnieuw proberen, met name bij grote gegevensvolumes.
API voor Cloud for Sustainability (preview)	Inkomend (pull)	Aangepaste API's die zijn gemaakt door Microsoft Cloud for Sustainability om toegang te krijgen tot uitstootgegevens met betrekking tot uw Azure-gebruik.	Filteren op de emissiegegevens is vereist wanneer de native Dashboard voor uitstootimpact-connector niet kan worden gebruikt.
API voor gegeneraliseerde berekening van uitstoot	Inkomend (push)	Aangepaste API's die zijn gemaakt door Microsoft Cloud for Sustainability om uitstoot voor activiteiten te berekenen met behulp van een rekenmodel zonder een berekeningsprofiel te maken.	Het activeren van uitstootberekening is vereist per gebeurtenis.
Aangepaste Dataverse-API	Inkomend	Uw eigen API maken in Dataverse.	Een of meer bewerkingen moeten worden geconsolideerd tot een enkele bewerking of er moet een nieuw type triggergebeurtenis worden geactiveerd.
Virtuele tabellen	Uitgaande (pull)	Maak verbinding met externe gegevensbronnen en behandel ze als native Dataverse-entiteiten.	Referentiegegevens en CRUD-scenario's met een laag volume ophalen.
Realtime invoegtoepassing	Uitgaand	Het andere systeem in realtime aanroepen tijdens een servergebeurtenis.	Geen gewenste optie vanwege de time-outlimiet van twee minuten voor kanalen, waardoor de gebruikerservaring voor synchrone registraties kan verslechteren.

De beschreven technologieopties kunnen verder worden uitgebreid om een intermediair systeem te introduceren dat fungeert als een relais voor de transactie. Relaisoptie ontkoppelt de bron- en doeltoepassing door de aanvraag- en responscommunicatie namens de toepassingen af te handelen, zoals weergegeven in de volgende afbeelding.

Asynchrone integratie

Asynchrone integratie is nodig wanneer er geen realtime responsafhankelijkheid is voor een bedrijfsproces of actie. Over het algemeen wordt het gebruikt wanneer er veel berichtcommunicatie is tussen toepassing en systemen. U kunt het gebeurtenisgestuurde consument- of publicatieabonneepatroon kiezen om de asynchrone integratie te implementeren.

In het gebeurtenisgestuurde consumentenpatroon in het volgende diagram gebruikt de afzender een gebeurtenisgestuurd raamwerk en maakt de consument rechtstreeks een binding met een gebeurtenis. Wanneer de gebeurtenis wordt geactiveerd, wordt de consument direct op de hoogte gebracht en ontvangt hij of zij de gegevens in het gebeurtenisbericht.

In het publicatieabonneepatroon in het volgende diagram maakt de uitgever een bericht in een gepubliceerde indeling en pusht dit naar een berichtenwachtrij met een of meer abonnees. De abonnee leest de berichtenwachtrij om het gepubliceerde bericht uit de wachtrij op te halen.

Deze asynchrone patronen kunnen worden geïmplementeerd met de technologieopties in de volgende tabel.

Technologieoptie	Gebeurtenisgestuurd of publicatieabonnee	Doel	Overwegingen	Wanneer gebruiken
Power Automate	Beide	Behoeften voor automatisering met weinig code.	Volg de Power Automate en de beperking van elke connector, zoals aanvraagbeperking.	Gebruik voor Dataverse-triggergebeurtenissen.
Aangepaste connectors op basis van Logic Apps-framework	Gebeurtenisgestuurd	Gegevensconnectors bouwen voor de Microsoft Sustainability Manager-oplossing om volledige gegevenssets te krijgen voor een of meer koolstofemissies en duurzaamheidscategorieën.	Moeten privacy-, beveiligings- en nalevingsbeoordelingen doorlopen voordat ze in productie worden genomen.	Gebruik van ISV-integratiescenario's waarbij geen native connectors bestaan.
Logic Apps en Azure Service Bus	Publicatieabonnee	Het ontvangen van berichten door de uitgever naar een servicebus en logische apps verbruikt het bericht om naar abonneetoepassingen te verzenden.	Volg de configuratie- en uitvoeringslimieten van Logic Apps.	Gebruik voor native triggers in Logic Apps-connectors en aangepaste integratie met meerdere abonneescenario's.
Azure Functions, Web Apps-functie van Azure App Service en Azure Service Bus	Publicatieabonnee	Gebruik een berichtenwachtrij om het communicatiekanaal tussen de toepassing en de exemplaren van de consumentenservice te implementeren.	Overweeg de volgorde van berichten en andere ontwerpoverwegingen.	Scenario's met een hoog volume en volatiliteit, waarbij integratie niet kan worden ontwikkeld met opties met weinig code (Power Automate of Logic Apps).
Asynchrone invoegtoepassing of service-eindpunt	Beide	De contextinformatie naar een wachtrij, onderwerp, webhook of event hub sturen.	Niet geschikt voor langlopende transacties.	Wanneer aan de integratievereiste meestal wordt voldaan door de Dataverse-context rechtstreeks naar het doel te sturen en het niet essentieel is om de berichten te ordenen.

Batchintegratie

Batching is de praktijk van het verzamelen en transporteren van een reeks berichten of records in een batch om verkeer en overhead te beperken. Dit patroon is ook geschikt voor het repliceren van de oorspronkelijke gegevens naar een replicaopslag voor analysedoeleinden. Dit batchintegratiepatroon kan worden geïmplementeerd met de technologieopties in de volgende tabel.

Technologieoptie	Inkomend/Uitgaand	Doel	Overwegingen	Wanneer gebruiken
Power Query-connectors voor Microsoft Sustainability Manager	Inkomend (pull)	Een robuuste catalogus van kant-en-klare en aangepaste connectors van operationele gegevensproviders.	Gebruik van alleen first-party connectors.	Scenario's die passen bij de gegevensstroom, ondersteund door Power Query-connectors die specifiek zijn voor Microsoft Sustainability Manager.
Ingebouwde Power Query-connectors	Inkomend (pull)	Gebruikers kunnen momenteel hun gegevens verbinden via bestanden met door komma's gescheiden waarden (CSV), Excel-bestanden en Open Data Protocol (OData), plus meer dan 40 connectors die beschikbaar zijn in Power Query.	Beperkte transformatiemogelijkheden die door Power Query kunnen worden ondersteund.	Scenario's voor gegevensopname of inkomende integratie die de connectors native ondersteunen.
Azure Data Factory	Inkomend (push)	Gegevensstromen maken om de gegevens te transformeren die zijn ontvangen van Dataverse of voorafgaand aan opname in Dataverse.	Servicelimieten voor Data Factory.	Scenario voor massaopname of gegevensexport met complexe transformatie in meerdere fasen.
SQL Server Integration Services (SSIS)	Inkomend (push)	Een connector van derden gebruiken om gegevens van en naar Dataverse te halen en te pushen.	Omdat het geen PaaS-oplossing is, moeten schaalbaarheid, geheugengebruik, prestaties en kosten worden geëvalueerd.	Beperkingen wanneer ETL-tools (extraheren, transformeren en laden) van de cloud mogelijk geen optie zijn.
Azure Synapse Link	Uitgaand (pull)	Replicatie van de Dataverse-gegevens naar Synapse Analytics of Data Lake voor analyse en aangepaste rapportage.	Tabellen die niet worden ondersteund.	Gegevensanalyses en aangepaste rapportage. Ook als tussenstap van gegevensexport.

Presentatie-integratie

Presentatie-integratie in Dataverse wordt meestal gebruikt wanneer u externe gegevens wilt weergeven binnen de Dataverse-gebruikersinterface. Deze benadering is handig wanneer u uw gebruikers een naadloze ervaring moet bieden terwijl ze toegang hebben tot gegevens van verschillende systemen zonder tussen verschillende toepassingen te schakelen. Dit integratiepatroon elimineert ook de noodzaak om gegevens te synchroniseren als de gegevens niet worden verbruikt door de doeltoepassing. De volgende tabel bevat enkele technologieopties voor presentatie-integratie.

Technologieoptie	Doel	Overwegingen	Wanneer gebruiken
Eigen native UI-integraties	Gebruik van Bing-kaarten, teams en andere first-party UI-integraties	In de meeste gevallen niet aanpasbaar	Specifieke scenario's die worden ondersteund in native UI-integratie
Aangepaste pagina's of ingesloten canvas-apps	Gebruikerservaring met het gebruik van de mogelijkheden van de canvas-app met aangepaste pagina's of het insluiten van een canvas-app in een modelgestuurde app	Bekende beperkingen	Bij voorkeur een integratiebenadering met weinig code en wanneer een canvas-app geschikt is voor bruikbaarheid
Power Apps-onderdeel	Een aangepast herbruikbaar besturingselement om de eindgebruiker weer te geven of ermee te communiceren terwijl het responsieve ontwerp behouden blijft	Beperkingen van Power Apps-onderdelen	Voorkeursmethode wanneer een aangepaste gebruikersinterface moet worden ontwikkeld binnen modelgestuurd bij afwezigheid van een canvas-app
Power BI-tegels	De Power BI-tegel weergeven in een modelgestuurd app-formulier	Power BI-licenties, autorisatie van Power BI-gegevens	Een Power BI-tegel weergeven in een modelgestuurde app
Power BI Embedded-dashboard	Power BI Embedded-dashboard weergeven in de modelgestuurde app	Power BI-licenties, autorisatie van Power BI-gegevens	De analyses weergeven die worden gehost in Power BI
Insluiten als iframe	De gebruikersinterface van het andere systeem insluiten in een modelgestuurde app	Eenmalige aanmelding, CORS-configuratie (Cross-Origin Resource Sharing) en responsief ontwerp	Complexe UI-scenario's waarbij geen service beschikbaar is
Aangepaste webresource	Een aangepaste UI-indeling maken binnen een modelgestuurde app	Responsief ontwerp	Scenario's waarbij andere UI-integraties geen optie zijn

Samenvatting van integratiepatronen

In de wereld van software-integratie zijn er verschillende patronen en mechanismen beschikbaar om gegevens uit te wisselen tussen verschillende systemen. Elk patroon heeft zijn eigen voor- en nadelen, en het kiezen van het juiste patroon kan grote invloed hebben op de prestaties en efficiëntie van de geïntegreerde systemen. Hieronder volgt een overzichtsweergave van deze integratiepatronen: realtime of synchroon, asynchroon, batching en presentatie. U kunt de mechanismen, triggers, voor- en nadelen en gebruiksscenario's voor elk patroon verkennen, zodat u een weloverwogen beslissing kunt nemen bij het selecteren van een integratiebenadering voor uw systeem.

Integratiepatroon	Mechanisme	Trigger	Voordelen	Nadelen	Wanneer gebruiken
Realtime of synchroon	Gegevens worden synchroon uitgewisseld, waarbij acties worden opgeroepen via point-to-point-integratie of met behulp van relais.	Gebruikersactie of systeemgebeurtenis.	Snelle aanvraag en respons. Realtime waarden en informatie.	Over het algemeen geen best practice om te gebruiken vanwege het risico dat processen vastlopen en nauwe koppelingen tot stand brengen. Risico op rimpeleffect door tijdelijke fouten. Gevoelig voor latentie.	Gebruik wanneer realtime informatie van cruciaal belang is.
Asynchroon	Gegevens worden onbeheerd uitgewisseld of opgenomen volgens een periodiek schema of als een groepsgewijze invoer met behulp van berichtpatronen.	Gepland voor een bepaalde periode of geactiveerd door een nieuw bericht dat is gepubliceerd door het bronsysteem.	Losse koppeling van systemen maakt de oplossing robuust. Taakverdeling over tijd en resources. Kan heel dicht bij realtime zijn. Tijdige foutafhandeling.	Vertraging in respons en zichtbaarheid van veranderingen in systemen.	Bijna realtime gegevenssynchronisatie nodig voor kleine of middelgrote gegevensvolumes
Batching	Batching is de praktijk van het verzamelen en transporteren van een reeks berichten of records in een batch om verkeer en overhead te beperken.	Geplande of handmatige trigger.	Heel geschikt voor gebruik met berichtenservices en andere asynchrone integratiepatronen. Minder individuele pakketten en minder berichtenverkeer.	Versheid van gegevens is minder. De belasting in het ontvangende systeem kan worden beïnvloed als bedrijfslogica wordt uitgevoerd bij aankomst van het bericht.	Scenario's met een hoog volume of volatiliteit waarbij het verzamelen en transporteren van een reeks berichten of records in een batch mogelijk is, scenario's voor gegevensreplicatie.
Presentatie	Informatie van het ene systeem wordt naadloos geïntegreerd in de gebruikersinterface van een ander systeem.	N.v.t.	Het elimineren van de complexiteit van gegevenssynchronisatie, omdat de gegevens in het oorspronkelijke systeem blijven.	Moeilijk om de gegevens te gebruiken voor berekeningen voor verwerking, meer complexiteit om te voldoen aan eenmalige aanmelding, cross-origin side scripting en autorisatie-uitlijning.	Wanneer aan de vereiste is voldaan door het bronsysteem of de gebruikersinterface rechtstreeks weer te geven zonder dat gegevens hoeven te worden gesynchroniseerd tussen bron- en doelsysteem.