- BLOB storage and providers
- Client resources
- Configuring episerver
- Configuring episerver.dataStore
- Configuring episerver.framework
- Configuring episerver.packaging
- Configuring episerver.search
- Configuring episerver.shell
- Configuring module.config
- Configuring staticFile
- Configuring episerver.basicAuthentication
- Configuring .NET SignalR
- Configuring Image Service
- Configuring link validation
- Reading application settings programmatically
- Page types and templates
- Block types and templates
- IContentRepository and DataFactory
- Persisting IContent instances
- ContentType attribute
- Grouping content types and properties
- EditHint in MVC
- Creating a page programmatically
- Selecting content
- Converting page types for pages
- Refactoring content type classes
- Multilingual content
- Assets and media
- Planning deployments
- Installing database schema
- Setting up multiple sites
- Content Delivery Network (CDN) Configuration
- Configuring your email server
- Automatic schema updates
- Storing UTC date and time in the database
- Database mode
- Deployment scenarios
- Dynamic content
- Dynamic data store
- Event management
- Scheduled jobs
- Search integration
- Searching and filtering
- Installing and deploying Search Service
- About Episerver full-text search client
- About Episerver full-text search service
- Configuring Episerver full-text search client
- Configuring Episerver full-text search service
- Searching for pages based on page type
- Adding search providers
- Authentication and authorization
- Virtual roles
- Configuring Active Directory membership provider
- Recommendations for ASP.NET security settings
- Securing edit and admin user interfaces
- Federated security
- Forms authentication
- OWIN authentication
- Configuring mixed-mode OWIN authentication
- Permissions to functions
- Protecting users from session hijacking
- Managing cookies on the website
- EPiServer AspNetIdentity
- Integrate Azure AD using OpenID Connect
- User interface
- Context-sensitive components
- Service locator
- Describing content in the UI
- Shell profile
- Store architecture
- Message service pool
- Publish and subscribe messaging system
- Introduction to Dojo
- Using jQuery
- Plugging in a gadget
- Creating a component
- Extending the navigation
- WebSocket support
- Dashboard gadgets
- Command Pattern
- Object editing
- User notifications
- Virtual path providers
Using user notifications [Beta]
[New in Episerver CMS Core 9.4]
Note: This is a pre-release API that is UNSTABLE and might not satisfy the compatibility requirements as denoted by its associated normal version.
The User Notifications framework is intended for sending user-to-user notification messages.
A message is posted to the message queue through the Notifier. The message queue is handled by a scheduled job which periodically calls the NotificationDispatcher. The NotificationDispatcher formats the message using a NotificationFormatter and then sends it using a NotificationProvider. You can create your own formatters and providers.
Every message is sent on a channel (identified by a channel name), which is a namespace that groups messages of a certain kind together. Messages in different channels are not mixed. You can create your own channel by coming up with a name to use when creating messages and providing a formatter that supports it.
The sender has no control of how the recipient receives the message. The recipient’s provider preferences for that channel determine how the message is actually sent (at the moment a default preference resolver should be used).
Note: Do not use generic names for channels, providers and formatters because they risk colliding with other names. Prefix the names with something unique.
- NotificationMessage. The default message type; handles the message at the next scheduled job.
- ScheduledNotificationMessage. Handles the message at the next scheduled job that occurs after the provided time.
- DelayedNotificationMessage. Handles the message at the next scheduled job that occurs after the provided time but provides a delay time instead of an actual time.
A user is an INotificationUser instance with a name and a display name.
To find users, get an instance of QueryableNotificationUserService and use the Find method to find users by part of a name or the Get method to get a specific user by name.
Use an instance of INotificationPreferenceRegister to register a default preference resolver for a channel and a provider. The resolver takes a user's name and returns a provider-specific address (for example, email addresses for the email provider).
Get an instance of the INotifier interface and use the PostNotification method to post a message (for one or more recipients) to the message queue. If a message has more than one recipient, it is stored internally as one message for each recipient. Hook into the NotificationPosted, NotificationSaved and NotificationFiltered events to get feedback on the result of the posting (per message).
The NotificationDispatcher is configured in and triggered by the scheduler. It retrieves the messages that are waiting to be sent and groups them by recipient and channel. For each group, a formatter and a provider is located (if available) to format and send the messages. If there is a problem sending the messages, they are put back in the waiting queue.
When one (or more) messages are sent, they first are routed through a formatter, which can transform the messages with custom formatting and/or combining several messages into one. A formatter has a name to identify it and a list of names that specifies which channels the formatter supports. If the message has a channel name that matches one of the supported names, that formatter is selected to format the message.
Note: If more than one formatter is found that matches the channel name, no message is sent and an error message is logged.
To create your own formatter, implement the INotificationFormatter interface, give it a name and a list of supported channels. The FormatMessages method formats, takes, and returns a list of messages. In the simplest case of formatting, the method should just return the incoming messages. It also can format each message by changing Content (and Subject) or combine several messages into one. Make sure to set the ContainedIDs to match the IDs of the combined messages. Message IDs that exist in an in-message but not in an out-message are considered completed and removed from the queue. If there is a problem formatting the messages, the formatter throws an exception and those messages are put back into the queue and tried again at the next scheduled job.
A provider is a component for sending notifications using a specific method of communication. The built-in EmailNotificationProvider, for example, handles the sending of emails. A provider has a name to identify it and a format-property that specifies the format the provider supports (max length and if it supports HTML).
You can write your own provider by implementing the INotificationProvider interface and optionally the INotificationProviderStatus interface, which lets you enable and disable a provider. The Send method handles the sending of messages, and you should call succeededAction or failedAction for each message.
Use the IUserNotificationRepository interface to list notifications with the GetUserNotification, GetUserNotifications and GetUserNotificationsCount methods. These methods are used in the Episerver user interface to show notifications.
To get formatted messages, extend the INotificationFormatter implementation with IUserNotificationFormatter and implement the FormatUserMessage method. When calling GetUserNotification(s), formatting is done depending on the formattingMode parameter.
It is possible to hook into the UserNotificationMissing event to get a callback when a specified notification cannot be found.
You can also use the IUserNotificationRepository interface to mark one or more notifications as read with one of the MarkUserNotification(s)AsRead methods. To listen to read notifications, hook into the UserNotificationRead and UserNotificationReads events.
Truncate message queue
Notifications are stored in the database and old notifications are deleted by the Notification Message Truncate scheduled job, which is set to run every night by default and removes all notifications older than 3 months.