Integreringsmönster för smart kontrakt

Smarta kontrakt representerar ofta ett affärsarbetsflöde som behöver integreras med externa system och enheter.

Kraven för dessa arbetsflöden omfattar ett behov av att initiera transaktioner i ett distribuerat transaktionsregister som innehåller data från ett externt system, en tjänst eller en enhet. De måste också ha externa system som reagerar på händelser som kommer från smarta kontrakt i ett distribuerat redovisningsregister.

Integreringen REST API meddelanden skickar transaktioner från externa system till smarta kontrakt som ingår i ett Azure Blockchain Workbench program. Den skickar även händelsemeddelanden till externa system baserat på ändringar som sker i ett program.

För dataintegreringsscenarier innehåller Azure Blockchain Workbench en uppsättning databasvyer som sammanslår en kombination av transaktionsdata från blockkedjan och metadata om program och smarta kontrakt.

Dessutom kan vissa scenarier, till exempel de som är relaterade till leveranskedjan eller media, också kräva integrering av dokument. Även Azure Blockchain Workbench inte tillhandahåller API-anrop för att hantera dokument direkt, kan dokument införlivas i ett blockkedjeprogram. Det här avsnittet innehåller även det mönstret.

Det här avsnittet innehåller de mönster som identifierats för att implementera var och en av dessa typer av integreringar i dina lösningar från end till end.

REST API-baserad integrering

Funktioner i den Azure Blockchain Workbench webbappen exponeras via REST API. Funktionerna omfattar Azure Blockchain Workbench överföring, konfiguration och administration av program, sändning av transaktioner till ett distribuerat transaktionsregister samt frågor om programmetadata och transaktionsregisterdata.

Den REST API används främst för interaktiva klienter som webb-, mobil- och robotprogram.

I det här avsnittet tittar vi på mönster som fokuserar på de aspekter av REST API som skickar transaktioner till ett distribuerat transaktionsregister och mönster som frågar efter data om transaktioner från Azure Blockchain Workbench utanför kedjans databas.

Skicka transaktioner till ett distribuerat transaktionsregister från ett externt system

Den Azure Blockchain Workbench REST API skickar autentiserade begäranden för att köra transaktioner i ett distribuerat transaktionsregister.

Körning av transaktioner sker med hjälp av den process som illustrerades tidigare, där:

• Det externa programmet autentiserar till den Azure Active Directory som etablerats som en del av Azure Blockchain Workbench distributionen.
• Behöriga användare får en bearer-token som kan skickas med begäranden till API:et.
• Externa program gör anrop till REST API med hjälp av bearer-token.
• Den REST API paketerar begäran som ett meddelande och skickar den till Service Bus. Härifrån hämtas, signeras och skickas den till lämpligt distribuerat redovisningsregister.
• Den REST API gör en begäran till Azure Blockchain Workbench SQL DB för att registrera begäran och upprätta den aktuella etableringsstatusen.
• SQL DB returnerar etableringsstatusen och API-anropet returnerar ID:t till det externa program som anropade det.

Köra frågor Blockchain Workbench metadata och distribuerade transaktionsregister

Data Azure Blockchain Workbench REST API autentiserade begäranden för att fråga efter information som rör smart kontraktskörning i ett distribuerat redovisningsregister.

Frågor sker med hjälp av den process som illustrerades tidigare, där:

1. Det externa programmet autentiserar till den Azure Active Directory som etablerats som en del av Azure Blockchain Workbench distributionen.
2. Behöriga användare får en bearer-token som kan skickas med begäranden till API:et.
3. Externa program gör anrop till REST API med hjälp av bearer-token.
4. Data REST API data för begäran från SQL DB och returnerar dem till klienten.

Meddelandeintegrering

Meddelandeintegrering underlättar interaktionen med system, tjänster och enheter där en interaktiv inloggning inte är möjlig eller önskvärd. Meddelandeintegrering fokuserar på två typer av meddelanden: meddelanden som begär att transaktioner ska köras på ett distribuerat transaktionsregister och händelser som exponeras av det transaktionskontot när transaktioner har skett.

Meddelandeintegrering fokuserar på körning och övervakning av transaktioner som rör skapande av användare, skapande av kontrakt och utförande av transaktioner i kontrakt och används främst av huvudlösa backend-system.

I det här avsnittet tittar vi på mönster som fokuserar på de aspekter av det meddelandebaserade API:et som skickar transaktioner till ett distribuerat transaktionsregister och mönster som representerar händelsemeddelanden som exponeras av det underliggande distribuerade transaktionskontot.

Leverans av envägshändelse från ett smart kontrakt till en händelsekonsument

I det här scenariot inträffar en händelse i ett smart kontrakt, till exempel en tillståndsändring eller körning av en viss typ av transaktion. Den här händelsen skickas via en Event Grid till nedströmskonsumenter, och dessa konsumenter vidta sedan lämpliga åtgärder.

Ett exempel på det här scenariot är att när en transaktion inträffar får en konsument en avisering och kan vidta åtgärder, till exempel registrera informationen i en SQL-databas eller Common Data Service. Det här scenariot är samma mönster som Workbench följer för att fylla i sin sql-databas utanför kedjan.

Ett annat alternativ är om ett smart kontrakt övergår till ett visst tillstånd, till exempel när ett kontrakt hamnar i ett OutOfCompliance. När den här tillståndsändringen inträffar kan det utlösa en avisering som skickas till en administratörs mobiltelefon.

Det här scenariot inträffar med hjälp av den process som illustrerades tidigare, där:

• Det smarta kontraktet övergår till ett nytt tillstånd och skickar en händelse till huvudboken.
• Huvudboken tar emot och levererar händelsen till Azure Blockchain Workbench.
• Azure Blockchain Workbench prenumererar på händelser från huvudboken och tar emot händelsen.
• Azure Blockchain Workbench publicerar händelsen till prenumeranter på Event Grid.
• Externa system prenumererar på Event Grid, använder meddelandet och vidta lämpliga åtgärder.

Envägshändelseleverans av ett meddelande från ett externt system till ett smart kontrakt

Det finns också ett scenario som flödar från motsatt riktning. I det här fallet genereras en händelse av en sensor eller ett externt system och data från händelsen ska skickas till ett smart kontrakt.

Ett vanligt exempel är leverans av data från finansiella marknader, till exempel priser på varor, aktie eller redovisning till ett smart kontrakt.

Direkt leverans av en Azure Blockchain Workbench i förväntat format

Vissa program är byggda för att Azure Blockchain Workbench och genererar och skickar meddelanden direkt i förväntade format.

Den här leveransen sker med hjälp av den process som illustrerades tidigare, där:

• En händelse inträffar i ett externt system som utlöser skapandet av ett meddelande för Azure Blockchain Workbench.
• Det externa systemet har kod som skrivits för att skapa det här meddelandet i ett känt format och skickar det direkt till Service Bus.
• Azure Blockchain Workbench prenumererar på händelser från Service Bus och hämtar meddelandet.
• Azure Blockchain Workbench initierar ett anrop till huvudboken och skickar data från det externa systemet till ett specifikt kontrakt.
• När meddelandet har mottagits övergår kontraktet till ett nytt tillstånd.

Leverans av ett meddelande i ett format som är okänt för Azure Blockchain Workbench

Vissa system kan inte ändras för att leverera meddelanden i standardformat som används av Azure Blockchain Workbench. I dessa fall kan befintliga mekanismer och meddelandeformat från dessa system ofta användas. Mer specifikt kan de interna meddelandetyperna i dessa system omvandlas med hjälp av Logic Apps, Azure Functions eller annan anpassad kod för att mappa till ett av de standardmeddelandeformat som förväntas.

Detta inträffar med hjälp av den process som illustrerades tidigare, där:

• En händelse inträffar i ett externt system som utlöser skapandet av ett meddelande.
• En logikapp eller anpassad kod används för att ta emot meddelandet och omvandla det till ett standardformaterat Azure Blockchain Workbench standardformat.
• Logikappen skickar det omvandlade meddelandet direkt till Service Bus.
• Azure Blockchain Workbench prenumererar på händelser från Service Bus och hämtar meddelandet.
• Azure Blockchain Workbench initierar ett anrop till huvudboken och skickar data från det externa systemet till en specifik funktion i kontraktet.
• Funktionen körs och ändrar vanligtvis tillståndet. Tillståndsändringen flyttar framåt det affärsarbetsflöde som återspeglas i det smarta kontraktet, vilket gör att andra funktioner nu kan köras efter behov.

Övergångskontroll till en extern process och väntar på slutförande

Det finns scenarier där ett smart kontrakt måste stoppa intern körning och lämna över till en extern process. Den externa processen skulle sedan slutföras, skicka ett meddelande till det smarta kontraktet och körningen skulle sedan fortsätta inom det smarta kontraktet.

Övergång till den externa processen

Det här mönstret implementeras vanligtvis med följande metod:

• Det smarta kontraktet övergår till ett visst tillstånd. I det här tillståndet kan antingen inga eller ett begränsat antal funktioner köras tills ett externt system vidtar en önskad åtgärd.
• Tillståndsändringen är en händelse för en underordnad konsument.
• Den underordnade konsumenten tar emot händelsen och utlöser extern kodkörning.

Retur av kontroll från det smarta kontraktet

Beroende på möjligheten att anpassa det externa systemet kan det hända att det inte kan leverera meddelanden i något av de standardformat som Azure Blockchain Workbench förväntar sig. Baserat på de externa systemens förmåga att generera ett av dessa meddelanden avgör vilken av följande två returvägar som används.

Direkt leverans av en Azure Blockchain Workbench i förväntat format

I den här modellen sker kommunikationen till kontraktet och efterföljande tillståndsändring efter föregående process där -

• När slutförandet har nåtts eller en specifik milstolpe i den externa kodkörningen skickas en händelse till den Service Bus som är ansluten till Azure Blockchain Workbench.

• För system som inte kan anpassas direkt för att skriva ett meddelande som överensstämmer med förväntningarna för API:et omvandlas det.

• Innehållet i meddelandet paketeras och skickas till en specifik funktion i det smarta kontraktet. Den här leveransen görs för den användare som är associerad med det externa systemet.

• Funktionen körs och ändrar vanligtvis tillståndet. Tillståndsändringen flyttar framåt det affärsarbetsflöde som återspeglas i det smarta kontraktet, vilket gör att andra funktioner nu kan köras efter behov.

Leverans av ett meddelande i ett format som är okänt för Azure Blockchain Workbench

I den här modellen där ett meddelande i ett standardformat inte kan skickas direkt sker kommunikationen till kontraktet och efterföljande tillståndsändring efter föregående process där:

1. När slutförandet har nåtts eller en specifik milstolpe i den externa kodkörningen skickas en händelse till den Service Bus som är ansluten till Azure Blockchain Workbench.
2. En logikapp eller anpassad kod används för att ta emot meddelandet och omvandla det till ett standardformaterat Azure Blockchain Workbench standardformat.
3. Logikappen skickar det omvandlade meddelandet direkt till Service Bus.
4. Azure Blockchain Workbench prenumererar på händelser från Service Bus och hämtar meddelandet.
5. Azure Blockchain Workbench initierar ett anrop till huvudboken och skickar data från det externa systemet till ett specifikt kontrakt.
6. Innehållet i meddelandet paketeras och skickas till en specifik funktion i det smarta kontraktet. Den här leveransen görs för den användare som är associerad med det externa systemet.
7. Funktionen körs och ändrar vanligtvis tillståndet. Tillståndsändringen flyttar framåt det affärsarbetsflöde som återspeglas i det smarta kontraktet, vilket gör att andra funktioner nu kan köras efter behov.

IoT-integrering

Ett vanligt integrationsscenario är inkludering av telemetridata som hämtas från sensorer i ett smart kontrakt. Baserat på data som levereras av sensorer kan smarta kontrakt vidta välgrundade åtgärder och ändra kontraktets tillstånd.

Om till exempel en lastbil som levererar medicin hade temperaturen soar till 110 grader kan det påverka effektiviteten hos medicinen och kan orsaka ett problem med allmän säkerhet om den inte upptäcks och tas bort från leveranskedjan. Om en drivrutin accelererar sin bil till 100 mil per timme kan den resulterande sensorinformationen utlösa en annullering av en försäkringsverksamhet av deras socialförsäkringsleverantör. Om bilen var en uthyrningsbil kan GPS-data indikera när drivrutinen gick utanför ett geografiskt område som omfattas av deras uthyrningsavtal och debitera en avgift.

Utmaningen är att dessa sensorer kan leverera data konstant och det är inte lämpligt att skicka alla dessa data till ett smart kontrakt. En vanlig metod är att begränsa antalet meddelanden som skickas till blockkedjan samtidigt som alla meddelanden levereras till ett sekundärt lager. Du kan till exempel leverera meddelanden som tas emot med ett fast intervall, till exempel en gång i timmen, och när ett inneslutet värde hamnar utanför ett överenskommet intervall för ett smart kontrakt. Genom att kontrollera värden som faller utanför toleranser säkerställer du att de data som är relevanta för kontraktens affärslogik tas emot och körs. Om du kontrollerar värdet vid intervallet bekräftas att sensorn fortfarande rapporterar. Alla data skickas till ett sekundärt rapporteringslager för att möjliggöra bredare rapportering, analys och maskininlärning. Även om det till exempel inte krävs sensoravläsningar för GPS varje minut för ett smart kontrakt, kan de tillhandahålla intressanta data som ska användas i rapporter eller mappningsvägar.

På Azure-plattformen görs vanligtvis integrering med enheter med IoT Hub. IoT Hub routning av meddelanden baserat på innehåll och möjliggör den typ av funktioner som beskrivs ovan.

Processen visar ett mönster:

• En enhet kommunicerar direkt eller via en fältgateway till IoT Hub.
• IoT Hub tar emot meddelandena och utvärderar meddelandena mot vägar som exempelvis kontrollerar innehållet i meddelandet. Rapporterar sensorn en temperatur som är större än 50 grader?
• Den IoT Hub skickar meddelanden som uppfyller kriterierna till en definierad Service Bus för vägen.
• En logikapp eller annan kod lyssnar på Service Bus som IoT Hub har upprättat för vägen.
• Logikappen eller annan kod hämtar och omvandlar meddelandet till ett känt format.
• Det transformerade meddelandet, som nu är i standardformat, skickas till Service Bus för Azure Blockchain Workbench.
• Azure Blockchain Workbench prenumererar på händelser från Service Bus och hämtar meddelandet.
• Azure Blockchain Workbench initierar ett anrop till huvudboken och skickar data från det externa systemet till ett specifikt kontrakt.
• När meddelandet har mottagits utvärderar kontraktet data och kan ändra tillståndet baserat på resultatet av utvärderingen, till exempel för en hög temperatur, ändra tillståndet till Följer inte efterlevnad.

Dataintegrering

Förutom REST och meddelandebaserad API ger Azure Blockchain Workbench även åtkomst till en SQL-databas som är ifylld med program- och kontraktsmetadata samt transaktionsdata från distribuerade transaktionsregister.

Dataintegreringen är välkänd:

• Azure Blockchain Workbench metadata om program, arbetsflöden, kontrakt och transaktioner som en del av det normala driftbeteendet.
• Externa system eller verktyg tillhandahåller en eller flera dialogrutor för att underlätta insamlingen av information om databasen, till exempel databasservernamn, databasnamn, typ av autentisering, inloggningsuppgifter och vilka databasvyer som ska användas.
• Frågor skrivs mot databasvyer för att underlätta nedströmsanvändning av externa system, tjänster, rapportering, utvecklarverktyg och produktivitetsverktyg för företag.

Lagringsintegrering

Många scenarier kan kräva att du inkluderar attesterbara filer. Av flera skäl är det olämpligt att placera filer i en blockkedja. I stället är en vanlig metod att utföra en kryptografisk hash (till exempel SHA-256) mot en fil och dela den hashen i ett distribuerat redovisningsregister. När som helst bör du returnera samma resultat om du utför hashen igen. Om filen ändras, även om bara en pixel ändras i en bild, returnerar hashen ett annat värde.

Mönstret kan implementeras där:

• Ett externt system bevarar en fil i en lagringsmekanism, till exempel Azure Storage.
• En hash genereras med filen eller filen och associerade metadata, till exempel en identifierare för ägaren, URL:en där filen finns osv.
• Hashen och eventuella metadata skickas till en funktion i ett smart kontrakt, till exempel FileAdded
• I framtiden kan filen och metadata hashas igen och jämföras med de värden som lagras i huvudboken.

Krav för att implementera integreringsmönster med hjälp av REST- och meddelande-API:er

För att underlätta möjligheten för ett externt system eller en enhet att interagera med det smarta kontraktet med hjälp av rest- eller meddelande-API:et måste följande ske:

1. I Azure Active Directory för konsortium skapas ett konto som representerar det externa systemet eller enheten.
2. Ett eller flera lämpliga smarta kontrakt för ditt Azure Blockchain Workbench-program har funktioner som definieras för att acceptera händelserna från ditt externa system eller din enhet.
3. Programkonfigurationsfilen för ditt smarta kontrakt innehåller rollen som systemet eller enheten har tilldelats.
4. Programkonfigurationsfilen för ditt smarta kontrakt identifierar i vilka tillstånd den här funktionen anropas av den definierade rollen.
5. Programkonfigurationsfilen och dess smarta kontrakt laddas upp till Azure Blockchain Workbench.

När programmet har laddats upp tilldelas Azure Active Directory för det externa systemet till kontraktet och den associerade rollen.

Testa externa systemintegreringsflöden innan du skriver integrationskod

Integrering med externa system är ett viktigt krav i många scenarier. Det är önskvärt att kunna validera smart kontraktsdesign före eller parallellt med utvecklingen av kod för att integrera med externa system.

Användningen av Azure Active Directory (Azure AD) kan avsevärt påskynda utvecklarens produktivitet och tid till värde. Mer specifikt kan kodintegreringen med ett externt system ta en icke-trivial tidsperiod. Genom att använda Azure AD och den automatiska genereringen av UX från Azure Blockchain Workbench kan du tillåta utvecklare att logga in på Blockchain Workbench som det externa systemet och fylla i värden från det externa systemet via UX. Du kan snabbt utveckla och validera idéer i en konceptbevismiljö innan integrationskoden skrivs för de externa systemen.