Making Decisions with a Workflow
Having a state for a model is quite common. The comment state is only determined by the spam checker. What if we add more decision factors?
We might want to let the website admin moderate all comments after the spam checker. The process would be something along the lines of:
- Start with a
submitted
state when a comment is submitted by a user; - Let the spam checker analyze the comment and switch the state to either
potential_spam
,ham
, orrejected
; - If not rejected, wait for the website admin to decide if the comment is good enough by switching the state to
published
orrejected
.
Implementing this logic is not too complex, but you can imagine that adding more rules would greatly increase the complexity. Instead of coding the logic ourselves, we can use the Symfony Workflow Component:
1
$ symfony composer req workflow
Describing Workflows
The comment workflow can be described in the config/packages/workflow.yaml
file:
To validate the workflow, generate a visual representation:
1
$ symfony console workflow:dump comment | dot -Tpng -o workflow.png
Note
The dot
command is a part of the Graphviz utility.
Using a Workflow
Replace the current logic in the message handler with the workflow:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
--- a/src/MessageHandler/CommentMessageHandler.php
+++ b/src/MessageHandler/CommentMessageHandler.php
@@ -6,7 +6,10 @@ use App\Message\CommentMessage;
use App\Repository\CommentRepository;
use App\SpamChecker;
use Doctrine\ORM\EntityManagerInterface;
+use Psr\Log\LoggerInterface;
use Symfony\Component\Messenger\Attribute\AsMessageHandler;
+use Symfony\Component\Messenger\MessageBusInterface;
+use Symfony\Component\Workflow\WorkflowInterface;
#[AsMessageHandler]
class CommentMessageHandler
@@ -15,6 +18,9 @@ class CommentMessageHandler
private EntityManagerInterface $entityManager,
private SpamChecker $spamChecker,
private CommentRepository $commentRepository,
+ private MessageBusInterface $bus,
+ private WorkflowInterface $commentStateMachine,
+ private ?LoggerInterface $logger = null,
) {
}
@@ -25,12 +31,18 @@ class CommentMessageHandler
return;
}
- if (2 === $this->spamChecker->getSpamScore($comment, $message->getContext())) {
- $comment->setState('spam');
- } else {
- $comment->setState('published');
+ if ($this->commentStateMachine->can($comment, 'accept')) {
+ $score = $this->spamChecker->getSpamScore($comment, $message->getContext());
+ $transition = match ($score) {
+ 2 => 'reject_spam',
+ 1 => 'might_be_spam',
+ default => 'accept',
+ };
+ $this->commentStateMachine->apply($comment, $transition);
+ $this->entityManager->flush();
+ $this->bus->dispatch($message);
+ } elseif ($this->logger) {
+ $this->logger->debug('Dropping comment message', ['comment' => $comment->getId(), 'state' => $comment->getState()]);
}
-
- $this->entityManager->flush();
}
}
The new logic reads as follows:
- If the
accept
transition is available for the comment in the message, check for spam; - Depending on the outcome, choose the right transition to apply;
- Call
apply()
to update the Comment via a call to thesetState()
method; - Call
flush()
to commit the changes to the database; - Re-dispatch the message to allow the workflow to transition again.
As we haven't implemented the admin validation, the next time the message is consumed, the "Dropping comment message" will be logged.
Let's implement an auto-validation until the next chapter:
1 2 3 4 5 6 7 8 9 10 11 12
--- a/src/MessageHandler/CommentMessageHandler.php
+++ b/src/MessageHandler/CommentMessageHandler.php
@@ -41,6 +41,9 @@ class CommentMessageHandler
$this->commentStateMachine->apply($comment, $transition);
$this->entityManager->flush();
$this->bus->dispatch($message);
+ } elseif ($this->commentStateMachine->can($comment, 'publish') || $this->commentStateMachine->can($comment, 'publish_ham')) {
+ $this->commentStateMachine->apply($comment, $this->commentStateMachine->can($comment, 'publish') ? 'publish' : 'publish_ham');
+ $this->entityManager->flush();
} elseif ($this->logger) {
$this->logger->debug('Dropping comment message', ['comment' => $comment->getId(), 'state' => $comment->getState()]);
}
Run symfony server:log
and add a comment in the frontend to see all transitions happening one after the other.
Finding Services from the Dependency Injection Container
When using dependency injection, we get services from the dependency injection container by type hinting an interface or sometimes a concrete implementation class name. But when an interface has several implementations, Symfony cannot guess which one you need. We need a way to be explicit.
We have just come across such an example with the injection of a WorkflowInterface
in the previous section.
As we inject any instance of the generic WorkflowInterface
interface in the contructor, how can Symfony guess which workflow implementation to use? Symfony uses a convention based on the argument name: $commentStateMachine
refers to the comment
workflow in the configuration (which type is state_machine
). Try any other argument name and it will fail.
If you don't remember the convention, use the debug:container
command. Search for all services containing "workflow":
1 2 3 4 5 6 7 8 9 10 11 12 13 14
$ symfony console debug:container workflow
Select one of the following services to display its information:
[0] console.command.workflow_dump
[1] workflow.abstract
[2] workflow.marking_store.method
[3] workflow.registry
[4] workflow.security.expression_language
[5] workflow.twig_extension
[6] monolog.logger.workflow
[7] Symfony\Component\Workflow\Registry
[8] Symfony\Component\Workflow\WorkflowInterface $commentStateMachine
[9] Psr\Log\LoggerInterface $workflowLogger
>
Notice choice 8
, Symfony\Component\Workflow\WorkflowInterface $commentStateMachine
which tells you that using $commentStateMachine
as an argument name has a special meaning.
Note
We could have used the debug:autowiring
command as seen in a previous chapter:
1
$ symfony console debug:autowiring workflow