Skip to content

Commit 183f2d8

Browse files
committed
restructure jobs
1 parent 51a4aeb commit 183f2d8

File tree

2 files changed

+64
-60
lines changed

2 files changed

+64
-60
lines changed

MyApp/_pages/background-jobs.md

Lines changed: 32 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -36,7 +36,9 @@ that can be used as internal invokable, inspectable and auto-retryable building
3636

3737
### Real Time Admin UI
3838

39-
Dashboard Summary of Executed, Failed and Cancelled Jobs and Worker Stats
39+
The Background Jobs Admin UI provides a real time view into the status of all background jobs including
40+
their progress, completion times, Executed, Failed and Cancelled Jobs, etc. which is useful for monitoring
41+
and debugging purposes.
4042

4143
![](/img/pages/jobs/jobs-dashboard.webp)
4244

@@ -178,35 +180,6 @@ the following options:
178180
- `ReplyTo` - Optional field for capturing where to send notification for completion of a Job
179181
- `Args` - Optional String Dictionary of Arguments that can be attached to a Job
180182

181-
### Executing non-durable jobs
182-
183-
`IBackgroundJobs` also supports `RunCommand` methods to be able to execute jobs transiently
184-
(i.e. non-durable), which is useful for commands that want to be serially executed by a named worker
185-
but don't need to be persisted.
186-
187-
You could use this to queue system emails to be sent by the same **smtp** worker and are happy to
188-
avoid tracking its state and execution history in the Jobs database.
189-
190-
```csharp
191-
var job = jobs.RunCommand<SendEmailCommand>(new SendEmail { ... },
192-
new() {
193-
Worker = "smtp"
194-
});
195-
```
196-
197-
In this case `RunCommand` returns the actual `BackgroundJob` instance that will be updated by
198-
the worker.
199-
200-
You can also use `RunCommandAsync` if you prefer to wait until the job has been executed. Instead
201-
of a Job it returns the **Result** of the command if it returned one.
202-
203-
```csharp
204-
var result = await jobs.RunCommandAsync<SendEmailCommand>(new SendEmail {...},
205-
new() {
206-
Worker = "smtp"
207-
});
208-
```
209-
210183
### Schedule Recurring Tasks
211184

212185
:::youtube DtB8KaXXMCM
@@ -247,6 +220,35 @@ last time the Recurring Task was run which is also viewable in the Jobs Admin UI
247220

248221
![](/img/pages/jobs/jobs-scheduled-tasks-last-job.webp)
249222

223+
### Executing non-durable jobs
224+
225+
`IBackgroundJobs` also supports `RunCommand` methods to be able to execute jobs transiently
226+
(i.e. non-durable), which is useful for commands that want to be serially executed by a named worker
227+
but don't need to be persisted.
228+
229+
You could use this to queue system emails to be sent by the same **smtp** worker and are happy to
230+
avoid tracking its state and execution history in the Jobs database.
231+
232+
```csharp
233+
var job = jobs.RunCommand<SendEmailCommand>(new SendEmail { ... },
234+
new() {
235+
Worker = "smtp"
236+
});
237+
```
238+
239+
In this case `RunCommand` returns the actual `BackgroundJob` instance that will be updated by
240+
the worker.
241+
242+
You can also use `RunCommandAsync` if you prefer to wait until the job has been executed. Instead
243+
of a Job it returns the **Result** of the command if it returned one.
244+
245+
```csharp
246+
var result = await jobs.RunCommandAsync<SendEmailCommand>(new SendEmail {...},
247+
new() {
248+
Worker = "smtp"
249+
});
250+
```
251+
250252
### Serially Execute Jobs with named Workers
251253

252254
By default jobs are executed immediately in a new Task, we can also change the behavior to

MyApp/_pages/releases/v8_04.md

Lines changed: 32 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -54,7 +54,9 @@ that can be used as internal invokable, inspectable and auto-retryable building
5454

5555
### Real Time Admin UI
5656

57-
Dashboard Summary of Executed, Failed and Cancelled Jobs and Worker Stats
57+
The Background Jobs Admin UI provides a real time view into the status of all background jobs including
58+
their progress, completion times, Executed, Failed and Cancelled Jobs, etc. which is useful for monitoring
59+
and debugging purposes.
5860

5961
![](/img/pages/jobs/jobs-dashboard.webp)
6062

@@ -196,35 +198,6 @@ the following options:
196198
- `ReplyTo` - Optional field for capturing where to send notification for completion of a Job
197199
- `Args` - Optional String Dictionary of Arguments that can be attached to a Job
198200

199-
### Executing non-durable jobs
200-
201-
`IBackgroundJobs` also supports `RunCommand` methods to be able to execute jobs transiently
202-
(i.e. non-durable), which is useful for commands that want to be serially executed by a named worker
203-
but don't need to be persisted.
204-
205-
You could use this to queue system emails to be sent by the same **smtp** worker and are happy to
206-
avoid tracking its state and execution history in the Jobs database.
207-
208-
```csharp
209-
var job = jobs.RunCommand<SendEmailCommand>(new SendEmail { ... },
210-
new() {
211-
Worker = "smtp"
212-
});
213-
```
214-
215-
In this case `RunCommand` returns the actual `BackgroundJob` instance that will be updated by
216-
the worker.
217-
218-
You can also use `RunCommandAsync` if you prefer to wait until the job has been executed. Instead
219-
of a Job it returns the **Result** of the command if it returned one.
220-
221-
```csharp
222-
var result = await jobs.RunCommandAsync<SendEmailCommand>(new SendEmail {...},
223-
new() {
224-
Worker = "smtp"
225-
});
226-
```
227-
228201
### Schedule Recurring Tasks
229202

230203
:::youtube DtB8KaXXMCM
@@ -265,6 +238,35 @@ last time the Recurring Task was run which is also viewable in the Jobs Admin UI
265238

266239
![](/img/pages/jobs/jobs-scheduled-tasks-last-job.webp)
267240

241+
### Executing non-durable jobs
242+
243+
`IBackgroundJobs` also supports `RunCommand` methods to be able to execute jobs transiently
244+
(i.e. non-durable), which is useful for commands that want to be serially executed by a named worker
245+
but don't need to be persisted.
246+
247+
You could use this to queue system emails to be sent by the same **smtp** worker and are happy to
248+
avoid tracking its state and execution history in the Jobs database.
249+
250+
```csharp
251+
var job = jobs.RunCommand<SendEmailCommand>(new SendEmail { ... },
252+
new() {
253+
Worker = "smtp"
254+
});
255+
```
256+
257+
In this case `RunCommand` returns the actual `BackgroundJob` instance that will be updated by
258+
the worker.
259+
260+
You can also use `RunCommandAsync` if you prefer to wait until the job has been executed. Instead
261+
of a Job it returns the **Result** of the command if it returned one.
262+
263+
```csharp
264+
var result = await jobs.RunCommandAsync<SendEmailCommand>(new SendEmail {...},
265+
new() {
266+
Worker = "smtp"
267+
});
268+
```
269+
268270
### Serially Execute Jobs with named Workers
269271

270272
By default jobs are executed immediately in a new Task, we can also change the behavior to

0 commit comments

Comments
 (0)