Integratiepatronen voor slimme contracten

Slimme contracten vertegenwoordigen vaak een zakelijke werkstroom die moet worden geïntegreerd met externe systemen en apparaten.

De vereisten van deze werkstromen omvatten de noodzaak om transacties te initiëren op een gedistribueerd grootboek dat gegevens van een extern systeem, service of apparaat bevat. Ze moeten ook externe systemen laten reageren op gebeurtenissen die afkomstig zijn van slimme contracten op een gedistribueerd grootboek.

De REST API en berichtenintegratie verzendt transacties van externe systemen naar slimme contracten die zijn opgenomen in een Azure Blockchain Workbench toepassing. Het verzendt ook gebeurtenismeldingen naar externe systemen op basis van wijzigingen die in een toepassing plaatsvinden.

Voor scenario's voor gegevensintegratie bevat Azure Blockchain Workbench een set databaseweergaven die een combinatie van transactionele gegevens uit de blockchain en metagegevens over toepassingen en slimme contracten samenvoegen.

Bovendien is voor sommige scenario's, zoals scenario's met betrekking tot de toeleveringsketen of media, mogelijk ook de integratie van documenten vereist. Hoewel Azure Blockchain Workbench API-aanroepen biedt voor het rechtstreeks verwerken van documenten, kunnen documenten worden opgenomen in een blockchain-toepassing. Deze sectie bevat ook dat patroon.

Deze sectie bevat de patronen die worden geïdentificeerd voor het implementeren van elk van deze typen integraties in uw end-to-end-oplossingen.

REST API-gebaseerde integratie

Mogelijkheden in de Azure Blockchain Workbench webtoepassing worden beschikbaar gemaakt via de REST API. Mogelijkheden zijn Azure Blockchain Workbench het uploaden, configureren en beheren van toepassingen, het verzenden van transacties naar een gedistribueerd grootboek en het uitvoeren van query's op metagegevens en grootboekgegevens van toepassingen.

De REST API wordt voornamelijk gebruikt voor interactieve clients, zoals web-, mobiele en bottoepassingen.

In deze sectie worden patronen bevraagd die zijn gericht op de aspecten van de REST API die transacties verzenden naar een gedistribueerd grootboek en patronen die gegevens opvragen over transacties uit de off chain-database van Azure Blockchain Workbench.

Transacties verzenden naar een gedistribueerd grootboek vanaf een extern systeem

De Azure Blockchain Workbench REST API geverifieerde aanvragen om transacties uit te voeren op een gedistribueerd grootboek.

Het uitvoeren van transacties vindt plaats met behulp van het proces dat eerder is weergegeven, waarbij:

• De externe toepassing wordt geverifieerd bij de Azure Active Directory ingericht als onderdeel van de Azure Blockchain Workbench implementatie.
• Geautoriseerde gebruikers ontvangen een Bearer-token dat kan worden verzonden met aanvragen naar de API.
• Externe toepassingen maken aanroepen naar de REST API met behulp van het bearer-token.
• De REST API verpakt de aanvraag als een bericht en verzendt deze naar de Service Bus. Hier wordt het opgehaald, ondertekend en verzonden naar het juiste gedistribueerde grootboek.
• De REST API een aanvraag naar de Azure Blockchain Workbench SQL DB om de aanvraag vast te leggen en de huidige inrichtingsstatus vast te stellen.
• De SQL-database retourneert de inrichtingsstatus en de API-aanroep retourneert de id naar de externe toepassing die deze heeft aangeroepen.

Query'Blockchain Workbench metagegevens en gedistribueerde grootboektransacties

De Azure Blockchain Workbench REST API geverifieerde aanvragen voor het opvragen van details met betrekking tot het uitvoeren van slimme contracten op een gedistribueerd grootboek.

Query's worden uitgevoerd met behulp van het proces dat eerder is weergegeven, waarbij:

1. De externe toepassing wordt geverifieerd bij de Azure Active Directory ingericht als onderdeel van de Azure Blockchain Workbench implementatie.
2. Geautoriseerde gebruikers ontvangen een Bearer-token dat kan worden verzonden met aanvragen naar de API.
3. Externe toepassingen maken aanroepen naar de REST API met behulp van het bearer-token.
4. De REST API query's op de gegevens voor de aanvraag van de SQL-database en retourneert deze naar de client.

Berichtintegratie

Berichtenintegratie vereent interactie met systemen, services en apparaten waarbij interactieve aanmelding niet mogelijk of wenselijk is. Berichtintegratie is gericht op twee soorten berichten: berichten die transacties aanvragen, worden uitgevoerd op een gedistribueerd grootboek en gebeurtenissen die door dat grootboek worden blootgesteld wanneer transacties hebben plaatsgevonden.

Berichtenintegratie is gericht op de uitvoering en bewaking van transacties met betrekking tot het maken, maken van contracten en het uitvoeren van transacties op contracten en wordt voornamelijk gebruikt door headless back-endsystemen.

In deze sectie worden patronen belicht die zijn gericht op de aspecten van de berichtgebaseerde API die transacties verzenden naar een gedistribueerd grootboek en patronen die gebeurtenisberichten vertegenwoordigen die worden weergegeven door het onderliggende gedistribueerde grootboek.

Een manier om gebeurtenissen van een slim contract te leveren aan een gebeurtenis-consument

In dit scenario treedt een gebeurtenis op binnen een slim contract, bijvoorbeeld een statuswijziging of de uitvoering van een specifiek type transactie. Deze gebeurtenis wordt via een Event Grid naar downstream-consumenten en deze consumenten nemen vervolgens de juiste acties.

Een voorbeeld van dit scenario is dat wanneer een transactie plaatsvindt, een consument wordt gewaarschuwd en actie kan ondernemen, zoals het vastleggen van de informatie in een SQL-database of de Common Data Service. Dit scenario is hetzelfde patroon dat Workbench volgt om de SQL-database buiten de keten te vullen.

Een andere reden is als een slim contract overgaat naar een bepaalde status, bijvoorbeeld wanneer een contract in een OutOfCompliance gaat. Wanneer deze statuswijziging zich voordeed, kan er een waarschuwing worden verzonden naar de mobiele telefoon van een beheerder.

Dit scenario vindt plaats met behulp van het proces dat eerder is weergegeven, waarbij:

• Het slimme contract gaat over naar een nieuwe status en verzendt een gebeurtenis naar het grootboek.
• Het grootboek ontvangt en levert de gebeurtenis aan Azure Blockchain Workbench.
• Azure Blockchain Workbench is geabonneerd op gebeurtenissen uit het grootboek en ontvangt de gebeurtenis.
• Azure Blockchain Workbench publiceert de gebeurtenis naar abonnees op de Event Grid.
• Externe systemen worden geabonneerd op Event Grid, verbruiken het bericht en nemen de juiste acties.

Een manier waarop een bericht van een extern systeem aan een slim contract wordt geleverd

Er is ook een scenario dat vanuit de tegenovergestelde richting stroomt. In dit geval wordt een gebeurtenis gegenereerd door een sensor of een extern systeem en moeten de gegevens van die gebeurtenis naar een slim contract worden verzonden.

Een veelvoorkomende voorbeeld is het leveren van gegevens uit financiële markten, bijvoorbeeld prijzen van producten, aandelen of diensten, aan een slim contract.

Directe levering van een Azure Blockchain Workbench in de verwachte indeling

Sommige toepassingen zijn gebouwd om te integreren met Azure Blockchain Workbench en genereren en verzenden berichten rechtstreeks in de verwachte indelingen.

Deze levering vindt plaats met behulp van het proces dat eerder is weergegeven, waarbij:

• Een gebeurtenis treedt op in een extern systeem dat het maken van een bericht voor Azure Blockchain Workbench.
• Het externe systeem heeft code geschreven om dit bericht in een bekende indeling te maken en verzendt het rechtstreeks naar de Service Bus.
• Azure Blockchain Workbench geabonneerd op gebeurtenissen uit de Service Bus wordt het bericht opgehaald.
• Azure Blockchain Workbench initieert een aanroep naar het grootboek en stuurt gegevens van het externe systeem naar een specifiek contract.
• Na ontvangst van het bericht wordt het contract over overgang naar een nieuwe status.

Levering van een bericht in een indeling die nog niet Azure Blockchain Workbench

Sommige systemen kunnen niet worden gewijzigd om berichten te leveren in de standaardindelingen die worden gebruikt door Azure Blockchain Workbench. In dergelijke gevallen kunnen bestaande mechanismen en berichtindelingen van deze systemen vaak worden gebruikt. Met name de systeemeigen berichttypen van deze systemen kunnen worden getransformeerd met behulp van Logic Apps, Azure Functions of andere aangepaste code om toe te staan aan een van de standaardberichtenindelingen die worden verwacht.

Dit gebeurt met behulp van het proces dat eerder is weergegeven, waarbij:

• Een gebeurtenis treedt op in een extern systeem dat het maken van een bericht activeert.
• Een logische app of aangepaste code wordt gebruikt om dat bericht te ontvangen en te transformeren naar een standaardbericht Azure Blockchain Workbench opgemaakt bericht.
• De logische app verzendt het getransformeerde bericht rechtstreeks naar de Service Bus.
• Azure Blockchain Workbench is geabonneerd op gebeurtenissen uit de Service Bus en haalt het bericht op.
• Azure Blockchain Workbench initieert een aanroep naar het grootboek en stuurt gegevens van het externe systeem naar een specifieke functie in het contract.
• De functie wordt uitgevoerd en wijzigt doorgaans de status. De statuswijziging verplaatst de zakelijke werkstroom die wordt weerspiegeld in het slimme contract, waardoor andere functies nu waar nodig kunnen worden uitgevoerd.

Overstappen van besturingselement naar een extern proces en wachten op voltooiing

Er zijn scenario's waarin een slim contract de interne uitvoering moet stoppen en aan een extern proces moet worden overge geven. Dat externe proces zou vervolgens worden voltooid, een bericht naar het slimme contract verzenden en de uitvoering zou vervolgens binnen het slimme contract worden voortgezet.

Overgang naar het externe proces

Dit patroon wordt doorgaans geïmplementeerd met behulp van de volgende benadering:

• Het slimme contract gaat over naar een specifieke status. In deze status kunnen geen of een beperkt aantal functies worden uitgevoerd totdat een extern systeem een gewenste actie onderneemt.
• De statuswijziging wordt aan een downstream-consument als een gebeurtenis aan het oppervlak genomen.
• De downstream consumer ontvangt de gebeurtenis en activeert de uitvoering van externe code.

Terug van controle van het slimme contract

Afhankelijk van de mogelijkheid om het externe systeem aan te passen, kan het al dan niet berichten leveren in een van de standaardindelingen die Azure Blockchain Workbench verwacht. Op basis van de mogelijkheid van externe systemen om een van deze berichten te genereren, wordt bepaald welke van de volgende twee retourpaden worden genomen.

Directe levering van een Azure Blockchain Workbench in de verwachte indeling

In dit model vindt de communicatie met het contract en de volgende statuswijziging plaats na het vorige proces, waarbij -

• Wanneer de voltooiing of een specifieke mijlpaal in de uitvoering van de externe code is bereikt, wordt er een gebeurtenis verzonden naar de Service Bus verbonden met Azure Blockchain Workbench.

• Voor systemen die niet rechtstreeks kunnen worden aangepast om een bericht te schrijven dat voldoet aan de verwachtingen van de API, wordt het getransformeerd.

• De inhoud van het bericht wordt verpakt en verzonden naar een specifieke functie in het slimme contract. Deze levering wordt uitgevoerd namens de gebruiker die is gekoppeld aan het externe systeem.

• De functie wordt uitgevoerd en wijzigt doorgaans de status. De statuswijziging verplaatst de zakelijke werkstroom die wordt weerspiegeld in het slimme contract, waardoor andere functies nu waar nodig kunnen worden uitgevoerd.

Levering van een bericht in een indeling die nog niet Azure Blockchain Workbench

In dit model waarbij een bericht in een standaardindeling niet rechtstreeks kan worden verzonden, vindt de communicatie met het contract en de volgende statuswijziging plaats na het vorige proces, waarbij:

1. Wanneer de voltooiing of een specifieke mijlpaal in de uitvoering van de externe code is bereikt, wordt er een gebeurtenis verzonden naar de Service Bus verbonden met Azure Blockchain Workbench.
2. Een logische app of aangepaste code wordt gebruikt om dat bericht te ontvangen en te transformeren naar een standaardbericht Azure Blockchain Workbench opgemaakt bericht.
3. De logische app verzendt het getransformeerde bericht rechtstreeks naar de Service Bus.
4. Azure Blockchain Workbench is geabonneerd op gebeurtenissen uit de Service Bus en haalt het bericht op.
5. Azure Blockchain Workbench initieert een aanroep naar het grootboek en stuurt gegevens van het externe systeem naar een specifiek contract.
6. De inhoud van het bericht wordt verpakt en verzonden naar een specifieke functie in het slimme contract. Deze levering wordt uitgevoerd namens de gebruiker die is gekoppeld aan het externe systeem.
7. De functie wordt uitgevoerd en wijzigt doorgaans de status. De statuswijziging verplaatst de zakelijke werkstroom die wordt weerspiegeld in het slimme contract, waardoor andere functies nu waar nodig kunnen worden uitgevoerd.

IoT-integratie

Een veelvoorkomende integratiescenario is het opnemen van telemetriegegevens die zijn opgehaald van sensoren in een slim contract. Op basis van gegevens die door sensoren worden geleverd, kunnen slimme contracten weloverwogen acties ondernemen en de status van het contract wijzigen.

Als een vrachtwagen die medicijnen levert bijvoorbeeld een temperatuur van 110 graden heeft bereikt, kan dit invloed hebben op de effectiviteit van de medicijnen en kan dit leiden tot een probleem met de openbare veiligheid als deze niet wordt gedetecteerd en verwijderd uit de toeleveringsketen. Als een auto is versneld tot 100 mijl per uur, kunnen de resulterende sensorgegevens een annulering van de verzekeringsmaatschappij door de verzekeringsprovider activeren. Als de auto een huurauto is, kunnen GPS-gegevens aangeven wanneer de autor zich buiten een geografie van de huurovereenkomst heeft gedijen en een boete in rekening kan brengen.

De uitdaging is dat deze sensoren constant gegevens kunnen leveren en dat het niet geschikt is om al deze gegevens naar een slim contract te verzenden. Een typische aanpak is het beperken van het aantal berichten dat naar de blockchain wordt verzonden tijdens het leveren van alle berichten aan een secundaire winkel. U kunt bijvoorbeeld berichten bezorgen die slechts met een vast interval worden ontvangen, bijvoorbeeld één keer per uur, en wanneer een ingesloten waarde buiten een overeengekomen bereik voor een slim contract valt. Door waarden te controleren die buiten toleranties vallen, zorgt u ervoor dat de gegevens die relevant zijn voor de bedrijfslogica van contracten worden ontvangen en uitgevoerd. Als u de waarde bij het interval controleert, wordt bevestigd dat de sensor nog steeds rapporteert. Alle gegevens worden verzonden naar een secundair rapportopslag om bredere rapportage, analyses en machine learning. Hoewel het bijvoorbeeld niet elke minuut nodig is om sensormetingen voor GPS voor een slim contract op te halen, kunnen ze interessante gegevens bieden die moeten worden gebruikt in rapporten of toewijzingsroutes.

Op het Azure-platform wordt de integratie met apparaten meestal uitgevoerd met IoT Hub. IoT Hub biedt routering van berichten op basis van inhoud en schakelt het type functionaliteit in dat eerder is beschreven.

In het proces wordt een patroon weergegeven:

• Een apparaat communiceert rechtstreeks of via een veldgateway met IoT Hub.
• IoT Hub ontvangt de berichten en evalueert de berichten op routes die bijvoorbeeld de inhoud van het bericht controleren. Rapporteert de sensor een temperatuur van meer dan 50 graden?
• De IoT Hub verzendt berichten die voldoen aan de criteria naar een Service Bus voor de route.
• Een logische app of andere code luistert naar de Service Bus die IoT Hub heeft ingesteld voor de route.
• De logische app of andere code haalt het bericht op en transformeert het naar een bekende indeling.
• Het getransformeerde bericht, nu in een standaardindeling, wordt verzonden naar de Service Bus voor Azure Blockchain Workbench.
• Azure Blockchain Workbench geabonneerd op gebeurtenissen uit de Service Bus wordt het bericht opgehaald.
• Azure Blockchain Workbench initieert een aanroep naar het grootboek en stuurt gegevens van het externe systeem naar een specifiek contract.
• Na ontvangst van het bericht evalueert het contract de gegevens en kan de status worden gewijzigd op basis van het resultaat van die evaluatie, bijvoorbeeld bij een hoge temperatuur, de status wijzigen in Niet-conform.

Gegevensintegratie

Naast REST en api op basis van berichten biedt Azure Blockchain Workbench ook toegang tot een SQL-database die is gevuld met metagegevens van toepassingen en contracten, evenals transactionele gegevens van gedistribueerde grootboeken.

De gegevensintegratie is bekend:

• Azure Blockchain Workbench slaat metagegevens over toepassingen, werkstromen, contracten en transacties op als onderdeel van het normale werkingsgedrag.
• Externe systemen of hulpprogramma's bieden een of meer dialoogvensters om het verzamelen van informatie over de database mogelijk te maken, zoals de naam van de databaseserver, de databasenaam, het type verificatie, aanmeldingsreferenties en welke databaseweergaven moeten worden gebruikt.
• Query's worden geschreven op basis van databaseweergaven om downstreamverbruik door externe systemen, services, rapportage, ontwikkelhulpprogramma's en productiviteitshulpprogramma's voor ondernemingen mogelijk te maken.

Opslagintegratie

In veel scenario's is het mogelijk nodig om attestable-bestanden op te nemen. Het is om meerdere redenen niet geschikt om bestanden in een blockchain te zetten. In plaats daarvan is een veelgebruikte methode om een cryptografische hash (bijvoorbeeld SHA-256) uit te voeren op een bestand en die hash te delen op een gedistribueerd grootboek. Het opnieuw uitvoeren van de hash op een toekomstig tijdstip moet hetzelfde resultaat retourneren. Als het bestand wordt gewijzigd, zelfs als slechts één pixel wordt gewijzigd in een afbeelding, retourneert de hash een andere waarde.

Het patroon kan worden geïmplementeerd waar:

• Een extern systeem houdt een bestand op in een opslagmechanisme, zoals Azure Storage.
• Er wordt een hash gegenereerd met het bestand of het bestand en de bijbehorende metagegevens, zoals een id voor de eigenaar, de URL waar het bestand zich bevindt, enzovoort.
• De hash en metagegevens worden verzonden naar een functie in een slim contract, zoals FileAdded
• In de toekomst kunnen het bestand en de metagegevens opnieuw worden gehasht en vergeleken met de waarden die zijn opgeslagen in het grootboek.

Vereisten voor het implementeren van integratiepatronen met behulp van de REST- en bericht-API's

Om de mogelijkheid voor een extern systeem of extern apparaat om te communiceren met het slimme contract met behulp van de REST- of bericht-API te vergemakkelijken, moet het volgende gebeuren:

1. In de Azure Active Directory voor het consortium wordt een account gemaakt dat het externe systeem of het externe apparaat vertegenwoordigt.
2. Een of meer geschikte slimme contracten voor uw Azure Blockchain Workbench hebben functies gedefinieerd om de gebeurtenissen van uw externe systeem of apparaat te accepteren.
3. Het toepassingsconfiguratiebestand voor uw slimme contract bevat de rol die aan het systeem of apparaat is toegewezen.
4. Het toepassingsconfiguratiebestand voor uw slimme contract identificeert in welke staten deze functie wordt aangeroepen door de gedefinieerde rol.
5. Het configuratiebestand van de toepassing en de slimme contracten worden geüpload naar Azure Blockchain Workbench.

Zodra de toepassing is geüpload, Azure Active Directory account voor het externe systeem toegewezen aan het contract en de bijbehorende rol.

Externe systeemintegratiestromen testen vóór het schrijven van integratiecode

Integratie met externe systemen is een belangrijke vereiste voor veel scenario's. Het is wenselijk om het ontwerp van slimme contracten te valideren vóór of parallel aan de ontwikkeling van code voor integratie met externe systemen.

Het gebruik van Azure Active Directory (Azure AD) kan de productiviteit van ontwikkelaars en de time-to-value sterk versnellen. Met name de code-integratie met een extern systeem kan een niet-triviale hoeveelheid tijd duren. Met behulp van Azure AD en het automatisch genereren van UX door Azure Blockchain Workbench kunt u ontwikkelaars toestaan om zich bij Blockchain Workbench aan te melden als het externe systeem en waarden van het externe systeem in te vullen via de UX. U kunt snel ideeën ontwikkelen en valideren in een proof-of-concept-omgeving voordat integratiecode wordt geschreven voor de externe systemen.