I want to undestand if the are some configuration to schedule the events rules that i have created, i follow the informations here Text
the process that i follow it was :
I Copy and enable a template event rule
I Modified the message template, to send the report event by email
but the only doubt that may a dont understand is who schedule this events , if i want to run daily or since 7 days, can this scheduler ?
and my last question i can test my rules?
who schedule this events
One does not schedule an event. An event happens ... and then the system responds to the event (using the rule that you have set up).
e.g.,
notify me if the system goes offline
notify me if the disks are > 95% full
If you want something to occur at a regularly scheduled time, then linux's "cron" facility would seem to be the way to go.
Related
We want to remind users to complete their workflow. These workflow events look like 'Workflow started', 'progressed stage 1', 'progressed stage 2',... 'Workflow ended' and they flow through Kafka. Each event has a unique identifier to identify a workflow attempt by the user.
How do we design a pipeline in Flink to detect workflows that have started but abandoned in the middle? Is there any established pattern for this?
You can use processFunction timers I think.
Timers
We ended up building with a timeout process function. We process each event of a workflow attempt and set a timer to fire.
Instant timerFireAt = event.getTimestamp().plusSeconds(timeoutDuration);
context.timerService().registerProcessingTimeTimer(timerFireAt.toEpochMilli();
This keeps getting updated with each incoming event of the same workflow attempt. On completion of the attempt, we delete the timer. If it's not deleted i.e. if there are no events for certain time, the timer fires.
We have a project in Octopus that has been configured to release to an environment on a schedule.
In the process definition we use a step template for Slack to send the team a notification when a release takes place. We would like to avoid sending this Slack message if the release was fired by the schedule - rather than user initiated.
I was hoping there would be a system variable that we could check before running the Slack step - but I can't seem to find anything documented as such, and google didn't turn anything up.
TIA
If you are using Octopus 2019.5.0 or later, there are two variables that will be populated if the deployment was created by a trigger.
Octopus.Deployment.Trigger.Id
Octopus.Deployment.Trigger.Name
You can see the details at https://github.com/OctopusDeploy/Issues/issues/5462
For your Slack step, you can use this run condition to skip it if the trigger ID is populated.
#{unless Octopus.Deployment.Trigger.Id}True#{/unless}
I hope that helps!
I have added some custom steps to some of my SSRS jobs however they are being removed after a couple of days every time. I know that if you add custom jobs and then change the report or the subscription in the UI then it overwrites the jobs. However they are not being touched yet they are still disappearing.
Has anyone else come across this problem ?
Although I often customize jobs that run subscriptions - no, I haven't come across that problem. I did not customize the jobs that were created automatically, instead I created my own ones.
For a subscription to successfully fire, the name of the job isn't important. Instead, the SQL code to execute the subscription (to be more specific: the SubscriptionID) is what you need to know. Since you were able to find the jobs that execute specific subscriptions, I think that you don't have a problem in finding this information, neither. The code you need looks like this:
exec [ReportServer].dbo.AddEvent #EventType='TimedSubscription', #EventData='<YourSubscriptionID>'
You can use this code in your own jobs as well, and it will work as long as the subscription is there.
The name of the SSRS-generated job is the ID of the report schedule that you define for the subscription. This name is needed by SSRS to know where to change the schedule when you change the schedule of the subscription. As you found out, SSRS resets these jobs not only when a subscription is changed. But you don't need all these jobs when creating your own jobs that run the subscription.
To get rid of the auto-generated job with that cryptic name, don't just delete it yourself (as SSRS would re-create it), instead change the schedule of the subscription to a shared schedule that will never run. For this, I created a shared schedule (under site settings) named "Disabled Schedule" and disabled that schedule.
I have several HTTP callouts that are in a schedulable and set to run ever hour or so. After I deployed the app on the app exchange and had a salesforce user download it to test, it seems the jobs are not executing.
I can see the jobs are being scheduled to run accordingly however the database never seems to change. Is there any reason this could be happening or is there a good chance the flaw lies in my code?
I was thinking that it could be permissions however I am not sure (its the first app I am deploying).
Check if the organisation of your end user has added your endpoint to "remote site settings" in the setup. By endpoint I mean an address that's being called (or just the domain).
If the class is scheduled properly (which I believe would be a manual action, not just something that magically happens after installation... unless you've used a post-install script?) you could also examine Setup -> Apex Jobs and check if there are any errors. If I'm right, there will be an error about callout not allowed due to remote site settings. If not - there's still a chance you'll see something that will make you think. For example batch job has executed successfully but there were 0 iterations -> problem?
Last but not least - you can always try the debug logs :) Enable them in Setup (or open the developer console), fire the scheduled class's execute() manually and observe the results? How to fire it manually? Sth like this pasted to "execute anonymous":
MySchedulableClass sched = new MySchedubulableClass();
sched.execute(null);
Or - since you know what's inside the scheduled class - simply experiment.
Please note that if the updates you might be performing somehow violate for example validation rules your client has - yes, the database will be unchanged. But in such case you should still be able to see failures in Setup -> Apex Jobs.
I'm hoping to avoid a hacked together mishmash to achieve something. I know it can be done with a mishmash but let's see if I'm missing a SIMPLE, easy way. This is Nagios Core 3.
I have a service. That service is checked 24x7x365. Notifications are sent 24x7x365, on WARNING and also on CRITICAL.
That is good--that is what I want.
However...now I want one single exception to that notification setup. NOTE: I do not want an exception to the monitoring setup--I want the console to always show the correct status, 24x7. I just want to make one exception for the notification (via email) on this service.
Here is the exception:
IF service state is WARN AND time of day is between 0300 and 0600, do NOT notify.
That's it. If it's CRITICAL, email-notify 24x7 (as it already does). If it's not between 3 and 6 a.m., notify regardless of WARN vs. CRIT (as it already does). The only exception is WARNING and 3-6 a.m.
Background: This is because we have maintenance that occurs every night between 3 and 6, which we've customized to produce a WARNING (not CRITICAL). I want notifications any time outside of this (admin may have accidentally launched maint in middle of day), and I want CRITICAL any time. I don't want to simply skip CHECKS during that time because I do want the console to be correct (a big bunch of yellows 0300-0600).
So, anyway, seems like I can kludge together a bunch of constructs but does anybody have a simple way to define this one "boolean AND" condition to the notification (only) schedule?
This is what scheduled downtime is for. If you create a scheduled downtime window alerts will be suppressed during this timeframe.
If that's not an option, then you need to different contacts for this service. 1 that notifies 24x7 and only on CRITICAL, and the other notifies 24x7(sans 3-6), and only receives WARNING notifications. Have them both point to the same contact email address.