We use something like this in our alert rules for a specific set of interfaces. We are using CurrentDateTime, but we found that those are treated like a String value and not a date/time value. Hope this helps you out! Let me know if you have more questions.
.png)
Make sure you go thru ALL of the documentation and are comfortable with it. Also, make sure you are mentally prepared with no distractions in your environment. You really need to be able to focus 100% on the exam. Good luck!
Certifications & Credly badges:
Carlotta has no Certifications & Credly badges yet.
Global Masters badges:
Followers:
Carlotta has no followers yet.
Following:
Carlotta has not followed anybody yet.
Enabling the Ens.Alert process allows you to route errors to an outbound operation based on the alert itself. We use this to either route alerts to an oncall analyst (and we change the contact information weekly as we rotate amongst our team), or for less critical alerts, we route them to a different email operation that just emails the team as a group. We have rules built around times so we don't get overnight pages for those less critical components based on their existence in a table, while still being able to receive those that are critical at any time. Example: We have scheduling interfaces that alert over holidays because there's no traffic from the business office, so we have a "holiday" table that we maintain yearly for workdays that are holidays (and additional mandatory PTO days) as well as a NoHolidayAlerts table, where we add either the service or the operation to that table that we don't want to receive alerts for. Then those alerts are suppressed on those days for those components. We also have a NoAfterHours table, as well as a NoAfterHoursNoSS (saturday/sunday) table, for those components that we don't want to hear from if it's not business hours M-F. Let me know if you need more info! We have quite a number of rules in our Ens.Alert router for these types of things.