Bepaalde gebeurtenisonderwerpen ondersteunen blokkeringsgebeurtenissen. Het gedrag van een uitbreidbaarheidsabonnement wordt bepaald door de ondersteuning die het onderwerp voor deze gebeurtenistypen biedt en uw configuratie van het abonnement.
Cloud Assembly-uitbreidbaarheidsabonnementen kunnen twee grote typen gebeurtenisonderwerpen gebruiken: niet-blokkerende en blokkerende gebeurtenisonderwerpen. Het type gebeurtenisonderwerp definieert het gedrag van het uitbreidbaarheidsabonnement.
Niet-blokkerende gebeurtenisonderwerpen
Met niet-blokkerende gebeurtenisonderwerpen kunt u alleen niet-blokkerende abonnementen maken. Niet-blokkerende abonnementen worden asynchroon geactiveerd en u kunt niet vertrouwen op de volgorde waarin de abonnementen worden geactiveerd.
Gebeurtenisonderwerpen blokkeren
Bepaalde gebeurtenisonderwerpen ondersteunen blokkering. Als een abonnement is gemarkeerd als 'blokkeren', worden alle berichten die voldoen aan de ingestelde voorwaarden niet ontvangen door andere abonnementen met overeenkomende voorwaarden totdat het runnable-item van het blokkerende abonnement wordt uitgevoerd.
Blokkerende abonnementen worden op volgorde van prioriteit uitgevoerd. De waarde 0 (nul) heeft de hoogste prioriteit. Als u voor hetzelfde gebeurtenisonderwerp meer dan één blokkerend abonnement hebt met hetzelfde prioriteitsniveau, worden de abonnementen op basis van de naam van het abonnement in omgekeerde alfabetische volgorde uitgevoerd. Wanneer alle blokkerende abonnementen zijn verwerkt, wordt het bericht gelijktijdig verstuurd naar alle niet-blokkerende abonnementen. Door de synchrone uitvoering van blokkerende abonnementen wordt de lading van de gebeurtenis steeds aangepast, zodat de bijgewerkte gebeurtenis wordt doorgestuurd naar de volgende abonnementen.
Met behulp van blokkerende gebeurtenisonderwerpen kunt u meerdere abonnementen beheren die afhankelijk zijn van elkaar.
U kunt bijvoorbeeld abonnementen hebben voor twee inrichtingswerkstromen, waarbij het tweede abonnement afhankelijk is van de resultaten van het eerste abonnement. Met het eerste abonnement wordt een eigenschap tijdens de inrichting gewijzigd, terwijl het tweede abonnement de nieuwe eigenschap, zoals een machinenaam, in een bestandssysteem registreert. Het abonnement ChangeProperty krijgt prioriteit 0 terwijl RecordProperty prioriteit 1 krijgt omdat het tweede abonnement de resultaten van het eerste abonnement gebruikt. Het abonnement ChangeProperty wordt uitgevoerd wanneer een machine wordt ingericht. Omdat de voorwaarden van het abonnement RecordProperty zijn gebaseerd op een voorwaarde na inrichting, wordt het abonnement RecordProperty geactiveerd door een gebeurtenis. Maar omdat de werkstroom ChangeProperty blokkerend is, wordt deze gebeurtenis pas ontvangen wanneer deze werkstroom is voltooid. Wanneer de machinenaam is gewijzigd en het eerste werkstroomabonnement gereed is, wordt het tweede werkstroomabonnement uitgevoerd om de machinenaam in het bestandssysteem te registreren.
Runnable-item voor herstel
Voor het blokkeren van gebeurtenisonderwerpen kunt u een runnable-item voor herstel toevoegen aan het abonnement. Het runnable-item voor herstel in een abonnement wordt uitgevoerd als het primaire runnable-item mislukt. U kunt bijvoorbeeld een werkstroomabonnement maken waarbij het primaire runnable-item een werkstroom is die records maakt in een CMDB-systeem zoals ServiceNow. Zelfs als het werkstroomabonnement mislukt, kunnen bepaalde records worden gemaakt in het CMDB-systeem. In dit scenario kan een runnable-item voor herstel worden gebruikt om de records op te schonen die door het mislukte runnable-item in het CMDB-systeem zijn achtergelaten.
Voor gebruikssituaties waarin meerdere abonnementen zijn opgenomen die afhankelijk zijn van elkaar, kunt u een eigenschap ebs.recover.continuation toevoegen aan het runnable-item voor herstel. Met deze eigenschap kunt u bepalen of de uitbreidbaarheidsservice moet doorgaan met het volgende abonnement in uw keten als het huidige abonnement mislukt.
