Calway.Automation 0.9.13

Calway.Automation

This library implements an Automation (Workflow/Statemachine) with strongly typed State

Usage

The main goal was to have a workflow in code where the state could be persisted (as json) in a database and based on the database record we could recreate the Automation and the State.

Create it in code

using Calway.Automation;

using ILoggerFactory factory = LoggerFactory.Create(builder => builder.AddConsole());
ILogger logger = factory.CreateLogger("EmailAutomation");

var automation = new EmailAutomation(logger);
automation.SetState(state => { 
	state.Email = "email@domain.com";
});
automation.NextStep();

Console.WriteLine(automation.LastStepResult.ToString());


public class EmailAutomationState 
{
	public string Email { get; set; }
	public DateTime FirstEmailSent { get; set; }
	public DateTime ReminderEmailSent { get; set; }
}

public class EmailAutomation : AutomationEngine<EmailAutomationState> 
{
	class FirstEmailStep: AutomationStep<EmailAutomationState>
	{
		public FirstEmailStep(string id, string name) : base(id, name)
        {
        }

		public override bool Action(EmailAutomationState state) 
		{
			// Add code to send the First Email
			state.FirstEmailSent = DateTime.UtcNow;
		}

		/// <summary>
		/// After sending the email we can wait for 14 days before we need to take action again. We could just check every day
		/// but when we already now that any Transition after this Step will be 14 days we can use that to optimize. Since not all
		/// transitions are based on time we need to choose a delay ourselves.
		/// </summary>
		public override DateTime? NextStepTriggerDate(EmailAutomationState state) => DateTime.UtcNow.AddDays(14);
	}

	class ReminderEmailStep: AutomationStep<EmailAutomationState>
	{
		public ReminderEmailStep(string id, string name) : base(id, name)
        {
        }

		public override bool Action(EmailAutomationState state) 
		{
			// Add code to send the Reminder Email
			state.ReminderEmailSent = DateTime.UtcNow;
		}

		/// <summary>
		/// After sending the reminder we will wait another 7 days
		/// </summary>
		public override DateTime? NextStepTriggerDate(EmailAutomationState state) => DateTime.UtcNow.AddDays(7);
	}

	/// <summary>
	/// After sending the First email we wait for 14 days before continuing.
	/// </summary>
	private bool ReminderEmailCondition(EmailAutomationState state) => state.FirstEmailSent < DateTime.UtcNow.AddDays(-14);

	public EmailAutomation(ILogger logger) : base(logger)
	{
		AddStep(new FirstEmailStep("first-email", "Send the first Email")
			AddConditionalTransition("reminder-email", ReminderEmailCondition);
		AddStep(new ReminderEmailStep("reminder-email", "Send a reminder Email");
	}
}

This automation start by sending an initial email, and then waits for 14 days before sending a reminder email and waiting 7 days before closing/ending this automation.

Reference

Configure options

Currently there are only two options that can be set.

• MaxStepsPerExecution, which controls the total number of steps executed by calling Execute(). This is mainly done to prevent infinite loops since we don't have workflow step cycle detection yet. The default is 20.
• SaveStepHistory, which controls where each step execution is logged in the AutomationState. This was added to be able to visualize how the automation was processed, but since complex automations might have loops that are executed multiple times this feature is turned off by default to prevent bloat in the AutomationState. By default is false.

Roadmap

These are features that are considered for adding

• Step execution cycle detection. Static flow analysis won't work due to the flexible guard clauses. Together with StepHistory we might detect we are running in circles, but even then, due to the flexibility of the guard clauses this might not be possible. As an alternative we might detect loops and halt further execution similar to the MaxStepsPerExecution.

• Investigate optimizing the AddStep flow. I don't like how each Step still have an Id and Name parameter in the constructor, we might as well hide that in the call to base. But this might the limit re-use of individual Steps