Domain events
Veracity Tenant Management (VTM) publishes whenever tenant data changes. Applications can subscribe to these events to stay synchronised with tenant state,...
Veracity Tenant Management (VTM) publishes domain events whenever tenant data changes. Applications can subscribe to these events to stay synchronised with tenant state, including users, groups, licenses, and elements.
These events allow applications to replicate tenant information locally for resiliency, performance, and automation workflows.
Domain events are delivered through Azure Service Bus and are part of the Veracity Domain Event system.
Domain event specification
The complete event specification is available as a downloadable document.
This document describes:
- event schema and payload structure
- Azure Service Bus integration
- message delivery and ordering
- event naming conventions
- subscription configuration
Applications that consume domain events should review this specification.
Why domain events are important
Applications using VTM often need to react to changes such as:
- users joining a tenant
- licenses being assigned
- group membership updates
- application installations
- element permissions changing
Instead of polling the API continuously, applications subscribe to domain events and react when changes occur.
Typical use cases include:
- synchronising tenant data to a local database
- updating application access control caches
- triggering provisioning workflows
- reacting to license changes
Event delivery
VTM domain events are delivered through Azure Service Bus.
Each application receives messages through a dedicated queue. Messages are delivered from the tenant topic, and events related to the same tenant are processed in order using the tenant identifier as the session key.
Developers enable event delivery by adding a Domain Event Management resource to their project in the Veracity developer portal.
The configuration provides a connection string used by the application to connect to the Service Bus.
Eventual consistency
VTM operates as an eventually consistent system.
When a write operation is performed through the API, the system returns:
HTTP 202 Accepted
This response means the request has been accepted but the change may not yet be persisted.
The change is processed asynchronously in the background.
Once processing finishes, VTM publishes a domain event that indicates whether the operation succeeded or failed.
Applications that perform write operations should listen for domain events to confirm that changes have been applied.
Event types
Events published by VTM are grouped into several categories.
Profile events
Events related to users within a tenant.
Examples:
com.veracity.profile.create
com.veracity.profile.replace
com.veracity.profile.delete
These events occur when:
- a user joins a tenant
- user information changes
- a user is removed from the tenant
Tenant events
Events describing changes to tenant configuration.
Example:
com.veracity.tenant.replace
These events occur when tenant settings such as affiliation modes or tenant properties are updated.
Application events
Events related to application lifecycle and licensing.
Examples:
com.veracity.tenantservice.create
com.veracity.tenantservice.replace
com.veracity.tenantservice.delete
com.veracity.service.subscription.add
com.veracity.service.subscription.replace
com.veracity.service.subscription.delete
These events occur when:
- an application is installed in a tenant
- licenses are added or removed
- subscription properties change
Group events
Events related to tenant groups.
Examples:
com.veracity.usergroup.create
com.veracity.usergroup.replace
com.veracity.usergroup.delete
These events are triggered when groups are created, modified, or deleted.
Membership events
Events related to group membership.
Examples:
com.veracity.group.member.add
com.veracity.group.member.replace
com.veracity.group.member.delete
These events occur when users or groups are added to or removed from groups.
Element events
Events related to application elements and element permissions.
Examples:
com.veracity.element.create
com.veracity.element.replace
com.veracity.element.delete
com.veracity.element.right.add
com.veracity.element.right.replace
com.veracity.element.right.delete
These events are triggered when elements or element permissions change.
Event verbs
Event types include a verb that indicates the action performed.
| Verb | Meaning |
|---|---|
| create | A new entity is created |
| add | A relationship or assignment is added |
| replace | An existing entity or assignment is updated |
| delete | An entity or relationship is removed |
Applications should interpret the verb to determine how to update internal data models.
Event payload structure
All domain events contain common metadata that allows applications to process them consistently.
Typical properties include:
| Property | Description |
|---|---|
| tenantId | Identifier of the tenant affected by the change |
| requestId | Identifier that correlates the API request with the event |
| name | Display name of the affected entity |
| properties | Extension properties associated with the entity |
Extension properties allow applications to attach service-specific metadata to tenant objects.
Consuming events in .NET
Veracity provides a strongly typed event handling framework for .NET applications.
NuGet package:
Veracity.Common.MessagingPack.Tenant
This package provides:
- strongly typed event models
- event handler infrastructure
- helper utilities for consuming domain events
Applications can implement event handlers to process specific event types when they are received.
Security considerations
When consuming domain events:
- store Service Bus connection strings securely (for example in a key vault)
- replicate only the data required by the application
- implement logging to detect and resolve processing failures
These practices help ensure reliable event processing and secure integration with the VTM event system.