Mönster för dataintegreringar för Microsoft Cloud for Sustainability

Datamodellen utgör grunden för Microsoft Cloud for Sustainability. Beroende på dataegendomens mognadsnivå kan lösningen kräva integrering med andra system. Att välja rätt mönster är mycket viktigt för att implementeringen ska lyckas.

I den här artikeln introduceras integrationsmönster, verktyg och beslutsfaktorer, medan en datainmatning en gång eller migreringsvägledning finns med i datamigreringsstrategin för Microsoft Sustainability Manager.

Behovet av integrering

I dagens snabba affärsmiljö står organisationer inför många utmaningar när det gäller att hantera och integrera sina system och data. Ett av de största hinderna är behovet av integrering mellan olika lösningar för lösningslösningen, som kan vara tidskrävande, komplext och tidskrävande.

Microsoft Cloud Industry Solutions erbjuder emellertid en lovande lösning på problemet. Genom att använda en Common Data Model som delas mellan flera tredjepartslösningar kan behovet av integrering minskas betydligt eller till och med elimineras. Information anpassningsnivå finns i dataegendomens mognadsnivåer. Det kan dock fortfarande krävas integreringar för följande scenarier:

• Processen sträcker sig över flera system och data måste synkroniseras från ett system till ett annat.
• Data delas eller utbyts mellan system när det behövs för utsläppsberäkningar.
• Data delas eller utbytes mellan system så att åtgärder som händer i ett system återspeglas i det andra systemet.
• Sammanställda data från ett system med en detaljerad datanivå utbyts till ett system med en representation av data på högre nivå.

Så här väljer du rätt integrationsmönster

Det finns många tekniska alternativ för integrationsutveckling, alla med egna fördelar och nackdelar. Om du vill identifiera rätt tilläggsmönster för integrering kan du överväga följande faktorer och väga dem över alternativen:

Beslutsfaktor	Beskrivning
Datatyper och format	Vilken typ av data och vilket format integreras?
Datavolatilitet	Ändras de data som behöver synkroniseras ofta?
Datavolym	Vilken volym har dataändringen som behöver synkroniseras?
Datatillgänglighet	När vill du att data ska vara klara, från källa till mål? Behövs informationen i realtid, eller behöver du bara samla in all information i slutet av dagen och skicka den i en schemalagd grupp till målet?
Serviceskydd och begränsning	Finns det några gränser baserat på tidsfönster, effektivitet och berättigande?
Dataomvandlingsnivå som krävs	Finns det något krav på att konvertera eller slå samman källdata till mål?
Utlösare och utlösaråtgärder	Vilken åtgärd utlöses när data skickas från källan till målet? Vilka specifika åtgärder ska automatiseras när data har kommit fram till målet?
Felhantering	Kommer det att finnas någon övervakning för att identifiera problem med gränssnitten?
Skalbarhet	Hur hanterar du den förväntade transaktionen på både kort och lång sikt?
System för post	Vilket system är det system där informationen finns eller vem som äger den?
Dataflödesriktning	Kommer målsystemet att behöva dra i det eller kommer källsystemet att behöva sända det?

Baserat å dessa faktorer kan du identifiera integrationsmönstret och även välja rätt verktyg eller teknik för implementering.

Integrationsmönster

Det finns flera mönster som kan användas vid integrering med Dataverse. Varje mönster representerar en form som kan användas med hjälp av en eller flera tekniker. Realisering av dessa mönster med teknik förklaras i följande avsnitt.

Realtids- eller synkron integrering

Integrering i realtid behövs när källsystemet (Program-A) skickar viss information och behöver ett omedelbart svar från målsystemet (Program-B) så att vissa uppföljningsåtgärder kan göras.

Det här mönstret kan implementeras med följande teknikalternativ:

Kommentar

Inkommande refererar till inkommande servicesamtal till Dataverse medan utgående refererar till utgående tjänstsamtal från Dataverse till andra system.

Teknikalternativ	Inkommande/utgående	Syfte	Använd när
Dataverse-API	Inkommande (push)	OData v4-implementering för att tillhandahålla CRUD-åtgärder med hjälp av en standarduppsättning gränssnitt, vilket ger ett gränssnitt som är öppet för publik.	Mest för transaktionell appintegrering när diskreta CRUD-operationer krävs. Kan även användas för anpassad integrering, men det kommer från komplexiteter som är relaterade till begränsning, parallellisering och återförsökslogik, särskilt vid hög grad av dataförseningar.
Cloud för hållbarhet API (förhandsversion)	Inkommande (pull)	Anpassade API:er som skapats för Microsoft Cloud for Sustainability att få åtkomst till data som är relaterade till din Azure-användning.	Filtrering på data för paneler krävs om det inbyggda anslutningsprogrammet för instrumentpanel för miljöpåverkan inte kan användas.
Beräknings-API för generaliserade utsläpp	Inkommande (push)	Anpassade API:er som skapats av Microsoft Cloud for Sustainability för att beräkna kalkyler för aktiviteter med hjälp av en beräkningsmodell utan att skapa en beräkningsprofil.	Utlösande utsläppsberäkning krävs enligt en händelse.
Anpassa Dataverse-API	Inkommande	Skapa ditt eget API i Dataverse.	En eller flera åtgärder måste konsolideras i en och samma åtgärd eller måste visa en ny typ av utlösande händelse.
Virtuella tabeller	Utgående (pull)	Anslut till externa datakällor och se till att de är inbyggda Dataverse-entiteter.	Dra referensdata och låg volym CRUD-scenarier.
Plugin-program i realtid	Utgående	Anropar det andra systemet i realtid i en händelse på serversidan.	Inte ett önskat alternativ på grund av en tidsgräns på två minuter för kanalen och kan försämra användarupplevelsen för synkrona registreringar.

De teknikalternativ som beskrivs kan utökas ytterligare för att introducera ett mellanliggande system som kan fungera som ett vidarebefordran för transaktionen. Med alternativet för vidarebefordra får käll- och målprogrammet att hantera begäran och svarskommunikationen för programmens räkning enligt följande bild.

Asynkron integrering

Asynkron integrering behövs om det inte finns något svarsberoende i realtid för en affärsprocess eller åtgärd. I allmänhet används den när det finns meddelandekommunikation med hög volym mellan program och system. Du kan välja det händelsestyrda konsument- eller publicering-prenumerant mönstret och implementera den asynkrona integreringen.

I det händelsestyrda konsumentmönstret i följande diagram antar avsändaren ett händelsedrivet ramverk och kunden skapar en bindning direkt till en händelse. När händelsen utlöses meddelas kunden direkt och tar emot data i händelsemeddelandet.

I mönster för publicering av prenumeranter i följande diagram skapar utgivaren ett meddelande i publicerat format och för det vidare till en meddelandekö som har en eller flera prenumeranter. Prenumeranterna läser meddelandekön för att hämta det publicerade meddelandet från kön.

Dessa asynkrona mönster kan implementeras med teknikalternativen i följande tabell.

Teknikalternativ	Händelsebaserad eller publiceringsbaserad prenumerant	Syfte	Att tänka på	Använd när
Power Automate	Båda	Automatisering lite kodning krävs.	Följ Power Automate och varje anslutningsbegränsning, såsom begränsning.	Använd för utlösande Dataverse-händelser.
Anpassade anslutningar som bygger på Logic Apps-ramverk	Händelsebaserad	Skapa datakopplingar för att Microsoft Sustainability Manager-lösningen för att få fullständiga datauppsättningar för en eller flera kategorier för miljöinformation och miljö.	Måste gå igenom sekretess-, säkerhets- och regelefterlevnadsgranskning innan de flyttas till produktion.	Användning av ISV-integrationsscenarier där det inte finns några inbyggda kopplingar.
Logic Apps och Azure Service Bus	Publicera-prenumerant	Om du tar emot meddelanden från utgivaren till en service bus- och logikappar används meddelandet för att skicka till prenumerantprogram.	Följ begränsningarna för konfiguration och körning av Logic Apps.	Använd för inbyggda utlösare i Logic Apps-anslutningar och anpassad integration med flera abonnentscenarier.
Azure-funktioner, webbappar för Azure App Service och Azure Service Bus	Publicera-prenumerant	Använd en meddelandekö för att implementera kommunikationskanalen mellan appen och instanserna av konsumenttjänsten.	Överväg meddelande ordning och andra designöverväganden.	Scenarier med höga volymer och scenarier för förfall där integrering inte kan utvecklas med lågkodsalternativ (Power Automate eller Logic Apps).
Asynkron plugin eller tjänst slutpunkt	Båda	Skicka sammanhangsinformationen till en kö, ämne, webhook eller händelsehubb.	Passar inte för transaktioner som körs länge.	När integrationsbehovet främst uppfylls genom att skicka Dataverse kontexten till målet och ordningen på meddelanden inte är helt avgörande.

Batchintegration

Batchbearbetning används för att samla in och transportera en uppsättning meddelanden eller poster i ett batch för att begränsa chatter och omkostnader. Det här mönstret gör det också möjligt att replikera originaldata till en repliklagring för analysändamål. Detta batchintegrationsmönster kan implementeras med teknikalternativen i följande tabell.

Teknikalternativ	Inkommande/utgående	Syfte	Att tänka på	Använd när
Power Query-anslutningsprogram för Microsoft Sustainability Manager	Inkommande (pull)	En robust katalog med fördefinierade och anpassade anslutningsprogram från driftdataprovider.	Användning av endast förstapart anslutningsprogram.	Scenarier som passar för dataflöden som stöds av Power Query anslutningsprogram som är specifika för Microsoft Sustainability Manager.
Inbyggda Power Query anslutningsprogram	Inkommande (pull)	Användare kan för närvarande ansluta sina data genom CSV-filer (kommaseparerade värden), Excel-filer och Open Data Protocol (OData), tillsammans med över 40 anslutningar som är tillgängliga i Power Query.	Begränsade omvandlingsfunktioner som Power Query kan användas.	Scenarier för datainmatning eller inkommande integrering som anslutningsprogram har stöd för inbyggt.
Azure Data Factory	Inkommande (push)	Skapa dataflöden för att omvandla de data som tagits emot Dataverse från eller före inmatning till Dataverse.	Begränsningar för tjänsten Data Factory.	Massinmatning eller dataexport scenario med komplex omvandling i flera steg.
SQL Server Integration Services (SSIS)	Inkommande (push)	Hämta och skicka data med hjälp av en tredjeparts anslutningsprogram till Dataverse.	Eftersom det inte är en PaaS-lösning bör skalning, minnesanvändning, prestanda och kostnad utvärderas.	Eventuella begränsningar när molnverktygen extraherar, omvandlar och läser in (ETL) kanske inte är ett alternativ.
Azure Synapse Link	Utgående (pull)	Replikera Dataverse-data till Synapse Analytics eller Data Lake för analys och anpassad rapportering.	Tabeller som inte stöds.	Dataanalys och anpassad rapportering. Även som ett mellanliggande steg för dataexport.

Integrering av presentationer

Presentationsintegrering i Dataverse används oftast när du vill visa externa data i Dataverse användargränssnittet. Den här metoden är användbar om du behöver ge användarna en smidig upplevelse när de får åtkomst till data från olika system utan att växla mellan olika program. Det här integreringsmönstret eliminerar också behovet av att synkronisera data om data inte förbrukas av målprogrammet. I följande tabell finns några tekniska alternativ för presentation integrering.

Teknikalternativ	Syfte	Att tänka på	Använd när
Integrerade användargränssnittsgränssnitt från första part	Användning av Bing maps, Teams och andra UI-integreringar från första part	Går inte att anpassa i de flesta fall	Specifika scenarier som stöds i inbyggt användargränssnittsintegrering
Anpassade sidor eller embedded arbetsyteappar	Användarupplevelse med att använda funktionerna för arbetsyteappen med anpassade sidor eller bädda in en arbetsyteapp i en modellbaserad app	Kända begränsningar	Föredraget att göra en integrationsstrategi med låg kod och när en arbetsyteapp är lämplig för användbarhet
Power Apps-komponent	En anpassad återanvändbar kontroll som visar eller interagerar med slutanvändaren samtidigt som den är oanvändbar	Power Apps komponentbegränsningar	Önskad metod när ett anpassat användargränssnitt utvecklas inom modelldrivet i avsaknad av en arbetsyteapp
Power BI paneler	Visa Power BI-panelen i ett modellbaserat appformulär	Power BI licensiera, auktorisering av Power BI data	Visa en Power BI-panel i en modellbaserad app
Power BI embedded instrumentpanel	Visar Power BI embedded instrumentpanel i en modellbaserad app	Power BI licensiera, auktorisering av Power BI data	Visa analyserna som finns i Power BI
embedded som iframe	Infoga det andra systemets användargränssnitt i en modellbaserad app	Enkel inloggning, resursdelning med flera ursprung (CORS) konfiguration och responsiv design	Komplexa användargränssnittsscenarier där det inte finns någon tillgänglig tjänst
Anpassad webbresurs	Skapa en anpassad användargränssnittslayout i en modellbaserad app	Responsiv design	Scenarier där andra användargränssnittsintegreringar inte är ett alternativ

Sammanfattning av integrationsmönster

I en värld av programvaruintegrering finns det olika mönster och mekanismer tillgängliga för att utbyta data mellan olika system. Varje mönster har sina egna fördelar och nackdelar och att välja rätt mönster kan påverka de integrerade systemens prestanda och effektivitet. Här följer en sammanfattning av dessa integrationsmönster: realtid eller synkron, asynkron, batchbearbetning och presentation. Du kan utforska de olika sätten, utlösare, fördelar och använda ärenden för varje mönster, så att du kan fatta ett väl underbyggda beslut när du väljer en integrationsmetod för ditt system.

Integrationsmönster	Mekanism	Utlösare	Fördelar	Nackdelar	Använd när
Realtids- eller synkron	Data utbytes synkront, anropa åtgärder via punkt till punkt-integrering eller med relä.	Användaråtgärd eller systemhändelse.	Snabb förfrågan och svarsrundtur. Värden och information i realtid.	Vanligtvis är det inte någon bra metod att använda sig av eftersom det finns risk för att processer fastnar och skapar tätt kopplad integrering. Risk för bruseffekt från övergående fel. Känslig för latens.	Använd när realtidsinformation är mycket viktig.
Asynkron	Data utbyts eller matas in obevakat i ett regelbundet schema eller som droppande med hjälp av meddelandemönster.	Schemalagd för en period eller utlöses av ett nytt meddelande som publicerats av källsystemet.	Lös koppling av system gör lösningen robust. Belastningsutjämning över tid och resurser. Kan vara mycket nära realtid. Felhantering i rätt tid.	Fördröjda svar och synlighet för ändringar i olika system.	Datasynkroniseringsbehov i nästan realtid för att föra in låga eller medellåga datavolymer
Batchbearbetning	Batchbearbetning används för att samla in och transportera en uppsättning meddelanden eller poster i ett batch för att begränsa chatter och omkostnader.	Schemalagd eller manuell utlösare.	Bra för användning med meddelandetjänster och andra asynkrona integrationsmönster. Färre enskilda paket och mindre meddelandetrafiken.	Datans korrekthet är lägre. Belastningen i mottagarsystemet kan påverkas om affärslogiken körs vid meddelandets ankomst.	Scenarier med hög volym eller volatilitet där det är möjligt att samla in och transportera en uppsättning meddelanden eller poster med batchbearbetning, datareplikeringsscenarier.
Presentation	Information från ett system integreras sömlöst i användargränssnittet i ett annat system.	Inte tillgänglig	Eliminerar komplexiteten i datasynkronisering, som för att data förblir i ursprungssystemet.	Det är svårt att använda data för beräkningar för bearbetning, mer komplexitet för att tillfredsställa enkel inloggning, sidoscript med flera ursprung och anpassning av autentisering.	När kravet uppfylls genom att visa källsystemet eller användargränssnittet direkt utan att behöva synkronisera data mellan käll- och målsystem.