Core Handlers
In this section, we'll go over the core message and processing handlers that the JobFlow system requires. These are required for a properly functioning JobFlow deployment.
New Items
There is a default web API provided in the Web
package to quickly stand up an ASP.Net API for creating new work items. Otherwise, creating new items within the system is as simple as using the NewWorkItem
service:
public class WorkItemController : ControllerBase
{
private readonly INewWorkItem _newWorkItem;
public WorkItemController(
INewWorkItem newWorkItem
)
{
_newWorkItem = newWorkItem;
}
[HttpPost]
public async Task<ActionResult> New([FromBody] WorkItemModel<JObject> workItemModel)
{
await _newWorkItem.CreateAsync(workItemModel);
return Ok();
}
}
That is all that is required to kick off the JobFlow system - the work item will be created and the rules will be executed.
However, other handles are required for the system to continue functioning properly. In particular, handling the responses from Job workers.
Job Work Response
By default, workers will place response messages in the configured response transport. You'll need to ensure those messages get to the appropriate JobFlow handler. The Job Work Response handler is automatically added the the dependency injection service collection with the IMessageHandler<JobWorkResponse>
interface.
ASP.Net Background Workers
JobFlow includes helper methods to allow easily setting up background transport listeners in ASP.Net (see Transport Listeners for more information on setting up your own worker listeners). An additional helper method allows for adding the Job Work Response handler to the service collection:
services.AddJobWorkResponseListener();
This will add an IHostedService that listens to the configured transport (see JobFlow Configuration for transport configuration information).
If, on the other, you want to user a web API instead of a transport to handle worker responses, the implementation would look similar to the following:
public class JobResponseController : ControllerBase
{
private readonly IMessageHandler<JobWorkResponse> _responseHandler;
public JobResponseController(
IMessageHandler<JobWorkResponse> responseHandler
)
{
_responseHandler = responseHandler;
}
[HttpPost]
public async Task<ActionResult> New([FromBody] Message<JobWorkResponse> jobResponse)
{
await _responseHandler.HandleAsync(jobResponse);
return Ok();
}
}
Note
This would require additional changes in how you use JobFlow. The system does not have an built-in method of using web APIs for message transport.
Azure Functions
Please see Function Deployment.
Scheduled Jobs
In order to be able to schedule any messages, the transport connection configured for JobSchedule
needs to support scheduling. There are two built-in transports that support scheduled messages. Hangfire or scheduled messages in Azure Service Bus.
Hangfire
If you're using Hangfire, then the only requirement is that the schedule background listener is configured:
services.AddJobFlow(c =>
{
// ... other configuration here ...
c.AddHangfireTransport();
c.AddScheduleListener();
}
Note
The method AddScheduleListener configures a background listener for the JobSchedule
connection. This method is not unique to the Hangfire transport and would work for any transport that support scheduling (such as Azure Service Bus, as documented below).
Azure Service Bus
When using Azure Functions to host the system, the schedule handler is simply another Function. See Function Deployment for more information.
However, if you are hosting the system within an ASP.Net or other application, then a background handler needs to be added to the service collection. As with the Hangfire scheduler, the only requirement is to create the appropriate background listener:
services.AddJobFlow(c =>
{
// ... other configuration here ...
c.AddAzureServiceBusTransport();
c.AddScheduleListener();
}
Azure Functions
Please see Function Deployment.