El El component ha estat des de fa molt de temps una de les joies més poderoses del marc, però poc utilitzades, i permet als desenvolupadors desconnectar la lògica del procés de negoci de l'estat de l'entitat, transformant els complexos controls d'estat de "codi espagueti" en gràfics direccionats nets i visualitzables. symfony/workflow Durant anys, però, el component tenia una estricta limitació arrelada en la seva implementació de les xarxes Petri: Un objecte estava en un lloc (estat), o no ho era.Encara que es podia estar en diversos llocs simultàniament (processament paral·lel), no es podia estar en el mateix lloc diverses vegades. Tokens were boolean Symfony 7.4 changes the game with Weighted Transitions. Aquest nou model introdueix Ara podeu modelar escenaris on les quantitats compten: “recollir 4 signatures”, “processar 5 articles de lot”, o “esperar que 3 subsistemes s’iniciïn”. multiplicity En aquest article anirem construint un Explorarem com configurar transicions ponderades, implementar la lògica d'entitat i verificar el flux amb proves rigoroses, tot utilitzant Symfony 7.4 i PHP 8.3. Multi-Signature Approval System El concepte (Petri Nets vs. màquines estatals) Abans d’escriure el codi, és crucial entendre per què existeix aquesta característica. Limitació de la màquina estatal Una màquina de l'estat és lineal; un ascensor també és , , o No es pot ser Això és perfecte per a estats més senzills (per exemple, ) i STOPPED MOVING_UP MOVING_DOWN MOVING_UP Order::STATUS_PAID El flux de treball (Petri Net) a Permet que un objecte estigui en diversos llocs alhora. En un procés de "Nou Empleat En embarcació", un empleat podria estar simultàniament en: Workflow 
 
 
 Propietats - Laptops Creació de correu electrònic_account Ambdós han de ser completats abans de traslladar-se a . onboarded La peça que falta: la multiplicitat Abans de Symfony 7.4, si necessitava “3 Gerents per aprovar una despesa”, no podia modelar això purament en el flux de treball. 
 
 
 
 Crear un lloc de espera_per_aprovació. Afegir un camp de comptador a la seva entitat ($approvalCount). Utilitzeu un escoltador d'esdeveniments Guard per comprovar si ($subject->getApprovalCount() >= 3) abans d'autoritzar la transició. amb El “ El motor de flux de treball entén nativament que el subjecte es troba en l'estat del flux de treball. Estat 3 vegades. Weighted Transitions counter approved Projecte de creació Creem un nou projecte Symfony i instal·lem els components necessaris. composer create-project symfony/skeleton:"7.4.*" fintech-approval
cd fintech-approval
composer require symfony/workflow symfony/framework-bundle symfony/orm-pack symfony/maker-bundle
 Per a aquest exemple, utilitzarem SQLite per a la simplicitat, però la lògica s'aplica a MySQL / PostgreSQL exactament el mateix. # .env
DATABASE_URL="sqlite:///%kernel.project_dir%/var/data.db"
 Configuració (la lògica bàsica) Aquí és on es produeix la màgia. definirem un flux de treball anomenat expense_approval. The Scenario: 
 
 
 
 
 
 S’elabora un informe de despeses (projecte). S’ha presentat el document (review_required) El pas ponderat: el sistema distribueix la sol·licitud a 3 aprovators requerits. Cadascun d’ells concedeix l’aprovació individualment. Un cop recollides les 3 aprovacions, la despesa es trasllada a ready_for_payment. Creació o actualització : config/packages/workflow.yaml # config/packages/workflow.yaml
framework:
    workflows:
        expense_approval:
            type: workflow # MUST be 'workflow', not 'state_machine'
            audit_trail:
                enabled: true
            marking_store:
                type: method
                property: currentState # This must hold an array
            
            supports:
                - App\Entity\ExpenseReport

            initial_marking: draft

            places:
                - draft
                - review_pool
                - approved_pool
                - ready_for_payment
                - rejected

            transitions:
                submit:
                    from: draft
                    to:
                        - place: review_pool
                          weight: 3 # <--- OUTPUT WEIGHT
                          
                approve:
                    from: review_pool
                    to: approved_pool
                    # Default weight is 1. One 'review_pool' token becomes one 'approved_pool' token.

                reject:
                    from: review_pool
                    to: rejected
                    # If rejected, we might want to clear all tokens, 
                    # but for simplicity, one rejection moves to rejected.

                finalize:
                    from:
                        - place: approved_pool
                          weight: 3 # <--- INPUT WEIGHT
                    to: ready_for_payment
 Desconstruir el Config 
 
 
 
 
 tipus: flux de treball: les transicions ponderades depenen de bolquers de token. Això no és possible en una màquina d'estat. submitTransition:- a: {loc: review_pool, pes: 3 } - Quan això s'incendia, thereview_poolplace rep 3 tokens.- Penseu en això com crear3 "tickets" que cal punxar. aprovaTransició:-de: review_pool, a: approved_pool.- Peso estàndard 1-a-1.- Com que tenim 3 tokens inreview_pool, podem disparar aquesta transició 3 vegades. finalizeTransition:- de: {loc: approved_pool, pes: 3 }- Aquesta transició es bloqueja fins que theapproved_poolconté exactament (o almenys) 3 tokens.- Una vegada que arriba la 3a aprovació, aquest camí es desbloqueja. L’entitat Necessitem una entitat que sostingui aquesta botiga de marques “Multi-State”. La propietat ha de ser una matriu per mantenir els comptes de token (per exemple, ) i currentState [‘review_pool’ => 2, ‘approved_pool’ => 1] 
namespace App\Entity;

use App\Repository\ExpenseReportRepository;
use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity(repositoryClass: ExpenseReportRepository::class)]
class ExpenseReport
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 255)]
    private string $description;

    #[ORM\Column]
    private float $amount;

    /**
     * Stores the workflow state.
     * For Weighted Workflows, this stores the places and their quantities.
     * Example DB content: {"review_pool": 2, "approved_pool": 1}
     */
    #[ORM\Column(type: 'json')]
    private array $currentState = [];

    public function __construct(string $description, float $amount)
    {
        $this->description = $description;
        $this->amount = $amount;
        // Initial marking is handled by the workflow component, 
        // but initializing to empty array is good practice.
    }

    public function getId(): ?int
    {
        return $this->id;
    }

    public function getDescription(): string
    {
        return $this->description;
    }

    public function getAmount(): float
    {
        return $this->amount;
    }

    public function getCurrentState(): array
    {
        return $this->currentState;
    }

    public function setCurrentState(array $currentState): self
    {
        $this->currentState = $currentState;
        return $this;
    }
}
 Comença la migració: php bin/console make:migration
php bin/console doctrine:migrations:migrate
 El servei Layer Per interactuar amb aquest flux de treball netament, hauríem de crear un servei. Aquest servei s'ocuparà de la lògica de "qui" està aprovant, encara que per a aquest tutorial, ens centrarem en la mecànica del flux de treball. 
namespace App\Service;

use App\Entity\ExpenseReport;
use Symfony\Component\Workflow\WorkflowInterface;
use Symfony\Component\Workflow\Registry;

readonly class ExpenseManager
{
    public function __construct(
        private Registry $workflowRegistry,
    ) {}

    public function submit(ExpenseReport $expense): void
    {
        $workflow = $this->getWorkflow($expense);
        
        if ($workflow->can($expense, 'submit')) {
            $workflow->apply($expense, 'submit');
        } else {
            throw new \LogicException('Cannot submit this expense report.');
        }
    }

    public function approve(ExpenseReport $expense): void
    {
        $workflow = $this->getWorkflow($expense);

        // In a real app, you would check "Is the current user one of the allowed approvers?" here.
        
        if ($workflow->can($expense, 'approve')) {
            $workflow->apply($expense, 'approve');
            
            // Check if we can auto-finalize (if 3 approvals are met)
            if ($workflow->can($expense, 'finalize')) {
                $workflow->apply($expense, 'finalize');
            }
        } else {
            throw new \LogicException('Approval not needed or not allowed.');
        }
    }
    
    public function getStatus(ExpenseReport $expense): array
    {
        // returns something like ['review_pool' => 2, 'approved_pool' => 1]
        return $expense->getCurrentState();
    }

    private function getWorkflow(ExpenseReport $expense): WorkflowInterface
    {
        return $this->workflowRegistry->get($expense, 'expense_approval');
    }
}
 La lògica de l’auto-finalització Nota el mètode d'aprovació. Després d'aplicar l'aprovació, comprovem immediatament pot ($expense, 'finalize'). 
 
 
 
 FirstApproval:-review_pool: 2-approved_pool: 1-finalize necessita 3 approved_pool. can(‘finalize’) retorna false. SecondApproval:-review_pool: 1-approved_pool: 2-can(‘finalize’) retorna fals. ThirdApproval:review_pool: 0approved_pool: 3finalize needs 3. can(‘finalize’) retorna true.We applyfinalize.New State:ready_for_payment: 1. Visualitzar el flux de treball Abans de provar, és increïblement útil visualitzar el gràfic, especialment amb els pesos involucrats. php bin/console workflow:dump expense_approval | dot -Tpng -o workflow.png
 Necessiteu graphviz instal·lat a la vostra màquina per utilitzar el punt. Si no el teniu, podeu col·locar la sortida de text en un visualitzador en línia de Graphviz. La sortida representarà visualment les fletxes amb etiquetes com el pes: 3, deixant clar que la transició enviada engendra múltiples tokens. Verificació (prova de la unitat) No només esperem que funcioni; ho demostrem. carregar la configuració actual del flux de treball i provar les transicions. KernelTestCase //tests/Workflow/ExpenseApprovalWorkflowTest.php
namespace App\Tests\Workflow;

use App\Entity\ExpenseReport;
use Symfony\Bundle\FrameworkBundle\Test\KernelTestCase;
use Symfony\Component\Workflow\WorkflowInterface;

class ExpenseApprovalWorkflowTest extends KernelTestCase
{
    private WorkflowInterface $workflow;

    protected function setUp(): void
    {
        self::bootKernel();
        $container = static::getContainer();
        $registry = $container->get('workflow.registry');
        
        // We create a dummy subject to get the workflow
        // In a real app, passing the class name to the registry is preferred if supported,
        // or fetching by name directly if you have a custom service alias.
        $subject = new ExpenseReport('Test', 100.0);
        $this->workflow = $registry->get($subject, 'expense_approval');
    }

    public function testWeightedApprovalFlow(): void
    {
        $expense = new ExpenseReport('MacBook Pro', 3000.00);

        // 1. Initial State
        $this->assertTrue($this->workflow->can($expense, 'submit'));
        $this->workflow->apply($expense, 'submit');

        // Verify tokens: Should be in review_pool 3 times
        $marking = $expense->getCurrentState();
        $this->assertArrayHasKey('review_pool', $marking);
        $this->assertEquals(3, $marking['review_pool'], 'Should have 3 pending reviews');

        // 2. First Approval
        $this->assertTrue($this->workflow->can($expense, 'approve'));
        $this->workflow->apply($expense, 'approve');
        
        $marking = $expense->getCurrentState();
        $this->assertEquals(2, $marking['review_pool']);
        $this->assertEquals(1, $marking['approved_pool']);

        // Check that we CANNOT finalize yet (need 3 approvals)
        $this->assertFalse($this->workflow->can($expense, 'finalize'), 'Should not finalize with only 1 approval');

        // 3. Second Approval
        $this->workflow->apply($expense, 'approve');
        $marking = $expense->getCurrentState();
        $this->assertEquals(1, $marking['review_pool']);
        $this->assertEquals(2, $marking['approved_pool']);

        // 4. Third Approval
        $this->workflow->apply($expense, 'approve');
        $marking = $expense->getCurrentState();
        
        // At this specific moment, review_pool is 0, approved_pool is 3
        $this->assertEquals(0, $marking['review_pool'] ?? 0);
        $this->assertEquals(3, $marking['approved_pool']);

        // 5. Finalize
        $this->assertTrue($this->workflow->can($expense, 'finalize'), 'Should be able to finalize now');
        $this->workflow->apply($expense, 'finalize');

        // 6. Verify End State
        $marking = $expense->getCurrentState();
        $this->assertArrayHasKey('ready_for_payment', $marking);
        $this->assertEquals(1, $marking['ready_for_payment']);
        // Previous tokens should be consumed
        $this->assertArrayNotHasKey('approved_pool', $marking);
    }
}
 Executa el test: php bin/phpunit tests/Workflow/ExpenseApprovalWorkflowTest.php
 Ús avançat i bones pràctiques Utilitzar enums per a llocs (Nou en 7.4) Symfony 7.4 també afegeix suport per a Enums de seguretat en els fluxos de treball. “Hi hauria d’haver un Enemic. review_pool namespace App\Enum;

enum ExpenseState: string
{
    case DRAFT = 'draft';
    case REVIEW_POOL = 'review_pool';
    case APPROVED_POOL = 'approved_pool';
    case READY = 'ready_for_payment';
    case REJECTED = 'rejected';
}
 A continuació, pot actualitzar el seu workflow.yaml (encara que YAML encara utilitza cadenes, el seu codi PHP pot utilitzar ) i ExpenseState::REVIEW_POOL->value Esdeveniments amb pesos Potser voleu evitar el mateix de l'aprovació 3 vegades. Transicions ponderades permeten la transició S’ha de trucar tres vegades, però el motor de flux de treball no sap qui l’ha trucat. person approve Per resoldre aquest problema, utilitzeu un escoltador de guàrdia. #[AsEventListener('workflow.expense_approval.guard.approve')]
public function preventDoubleApproval(GuardEvent $event): void
{
    /** @var ExpenseReport $expense */
    $expense = $event->getSubject();
    $user = $this->security->getUser();

    // Imagine the entity has a list of who already approved
    if ($expense->hasApproved($user)) {
        $event->setBlocked(true, 'You have already approved this expense.');
    }
}
 El procés de neteja de token (Token Cleanup) Un dels reptes amb tokens ponderats és la neteja. Si tenim 2 aprovacions i la tercera persona truca , què passa amb els 2 tokens asseguts en ? reject approved_pool En un flux de treball estàndard, passar a Podria deixar aquells esclatar tokens (creant un estat zombie on l'informe és tant rebutjat com parcialment aprovat). rejected approved_pool El La transició hauria de consumir idealment No obstant això, el consum dinàmic no és recolzat exclusivament en YAML (no es pot dir "consumir TOTS"). reject all Utilitzar un subscriptor d'esdeveniments en , podeu resetar manualment la botiga de marcatge. workflow.entered.rejected public function onRejected(Event $event): void
{
    $expense = $event->getSubject();
    // Force reset state to ONLY rejected
    $expense->setCurrentState(['rejected' => 1]);
}
 Conclusió Simfonia 7.4 En permetre que múltiples instàncies d'un estat (tokens) existeixin simultàniament, ara podem modelar sistemes de votació, línies de fabricació d'assemblatge i lògica de processament de lot directament en la configuració, reduint dràsticament la quantitat de caldereta PHP personalitzada necessària. Weighted Workflow Transitions Key Takeaways: 
 
 
 
 
 Multiplicitat: Els llocs poden contenir múltiples tokens, permetent l'acumulació paral·lela d'estat. Configuració: utilitzeu el pes de les definicions a (sortida) i des (entrada) per controlar el flux de token. Emmagatzematge: Assegureu-vos que la propietat de Marking Store és una matriu (per exemple, una columna JSON) per rastrejar els comptes de token per lloc. Verificació: utilitzeu sempre el comandament workflow:dump i escriviu proves KernelTestCase per demostrar la lògica del gràfic abans de desplegar-lo. Aquesta característica solidifica el component de Workflow de Symfony com la solució PHP de primer nivell per a la gestió de l'estat, permetent eliminar propietats fràgils i confiar en una arquitectura matemàticament sòlida. Estem en contacte L'adopció d'aquests patrons avançats pot simplificar significativament la seva lògica de domini, però la transició no sempre és òbvia.Si voleu modernitzar la vostra pila de Symfony, necessiteu un segon parell d'ulls sobre la vostra arquitectura, o simplement voleu sorprendre les últimes implementacions de Petri net, m'agradaria escoltar de vostè. Contacta amb mi a Linkedin ( ) per continuar la conversa sobre l'arquitectura PHP moderna. https://www.linkedin.com/in/matthew-mochalkin/ https://www.linkedin.com/in/matthew-mochalkin/

Read My Stories

Aquest àudio és produït a l'idioma original de la història!

Com es pot construir un sistema d'aprovació FinTech amb Symfony 7.4

About Author

COMENTARIS

Etiquetes penjant

AQUEST ARTICLE VA SER PRESENTAT A

Related Stories

How to Turn Year-End Reflections into Q1 Content Gold

Why Over-Explaining Your Tech Is Killing Your Content Strategy

Generar líders de qualitat ASAP: HackerNoon's Content-Relevant Niche Ads FTW

New Features: They're Everything, We're Just Ken

How to Turn Year-End Reflections into Q1 Content Gold

Why Over-Explaining Your Tech Is Killing Your Content Strategy

Generar líders de qualitat ASAP: HackerNoon's Content-Relevant Niche Ads FTW

New Features: They're Everything, We're Just Ken

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps