El El componente ha sido durante mucho tiempo una de las joyas más poderosas, pero poco utilizadas, del marco. Permite a los desarrolladores desconectar la lógica del proceso de negocio del estado de la entidad, transformando los controles de estado complejos de "código de espagueti" en gráficos dirigidos limpios y visualizables. symfony/workflow Durante años, sin embargo, el componente tuvo una estricta limitación enraizada en su implementación de las redes Petri: Un objeto estaba en un lugar (estado), o no estaba.Aunque usted podría estar en varios lugares simultáneamente (procesamiento paralelo), usted no podía estar en el mismo lugar varias veces. Tokens were boolean Symfony 7.4 changes the game with Weighted Transitions. Esta nueva característica introduce Ahora puede modelar escenarios donde las cantidades importan: "recoger 4 firmas", "procesar 5 elementos de lote" o "esperar que 3 subsistemas se inicien". multiplicity En este artículo, vamos a construir un sólido Exploraremos cómo configurar transiciones ponderadas, implementar la lógica de la entidad y verificar el flujo con pruebas rigurosas, todo usando Symfony 7.4 y PHP 8.3. Multi-Signature Approval System El concepto (Petri Nets vs. máquinas estatales) Antes de escribir código, es crucial comprender por qué existe esta característica. La limitación de la máquina estatal Una máquina de estado es lineal; un ascensor también es , de , o No puede ser Esto es perfecto para estados más simples (por ejemplo, ) de STOPPED MOVING_UP MOVING_DOWN MOVING_UP Order::STATUS_PAID El flujo de trabajo (Petri Net) a permite que un objeto se sienta en varios lugares a la vez. En un proceso de "Nuevo Empleado en embarque", un empleado puede estar simultáneamente en: Workflow 
 
 
 Proyecto - Laptops Crear una cuenta de correo electrónico Ambos deben ser completados antes de trasladarse a . onboarded La pieza perdida: la multiplicidad Antes de Symfony 7.4, si necesitabas “3 Gerentes para aprobar un gasto”, no podías modelar esto puramente en el flujo de trabajo. 
 
 
 
 Crear una ubicación de espera_para_aprobación. Añade un campo de contraseña a su entidad ($approvalCount). Utilice un escuchador de eventos Guard para comprobar si ($subject->getApprovalCount() >= 3) antes de permitir la transición. con El “ ” es ahora parte del estado del flujo de trabajo mismo. El motor del flujo de trabajo entiende nativamente que el sujeto está en el Estado 3 veces. Weighted Transitions counter approved Proyecto Instalación Vamos a crear un nuevo proyecto Symfony e instalar los componentes necesarios. 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
 Para este ejemplo, usaremos SQLite para la simplicidad, pero la lógica se aplica a MySQL/PostgreSQL exactamente lo mismo. # .env
DATABASE_URL="sqlite:///%kernel.project_dir%/var/data.db"
 Configuración (la lógica del núcleo) Aquí es donde ocurre la magia. Definiremos un flujo de trabajo llamado expense_approval. The Scenario: 
 
 
 
 
 
 Se crea un informe de gastos (proyecto). Se ha presentado (review_required) El paso ponderado: El sistema distribuye la solicitud a 3 aprobadores necesarios. Cada autor otorga la aprobación individualmente. Una vez que se han recogido 3 aprobaciones, el gasto se desplaza a ready_for_payment. Crear o actualizar : 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
 Desarrollar el Config 
 
 
 
 
 tipo: flujo de trabajo: las transiciones ponderadas dependen de buckets de token. Esto no es posible en una máquina de estado. submitTransition:- a: {lugar: review_pool, peso: 3 } - Cuando este incendio, thereview_poolplace recibe 3 tokens.- Piensa en esto como crear3 “tickets” que necesitan ser golpeados. aprobarTransition:-de: review_pool, a: approved_pool.- Peso estándar 1-a-1.- Debido a que tenemos 3 tokens inreview_pool, podemos disparar esta transición 3 veces. finalizeTransition:- de: {lugar: aprobado_pool, peso: 3 }- Esta transición se bloquea hasta que el aprobado_poolcontiene exactamente (o al menos) 3 tokens.- Una vez que entra la 3a aprobación, este camino se desbloquea. La entidad Necesitamos una entidad que apoye esta tienda de marcas “Multi-State”. La propiedad debe ser una matriz para mantener las cuentas de token (por ejemplo, ) de 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;
    }
}
 Ejecutar la migración: php bin/console make:migration
php bin/console doctrine:migrations:migrate
 El servicio Layer Para interactuar con este flujo de trabajo de forma limpia, deberíamos crear un servicio.Este servicio manejará la lógica de “quién” está aprobando, aunque para este tutorial nos centraremos en la mecánica del flujo de trabajo. 
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 “auto-finalizar” Nota el método de aprobación.Después de aplicar aprobar, inmediatamente comprobamos que puede ($expense, ‘finalizar’). 
 
 
 
 FirstApproval:-review_pool: 2-approved_pool: 1-finalize needs 3 approved_pool. can(‘finalize’) devuelve falso. SecondApproval:-review_pool: 1-approved_pool: 2-can(‘finalize’) devuelve falso. ThirdApproval:review_pool: 0approved_pool: 3finalize needs 3. can(‘finalize’) devuelve true.We applyfinalize.New State:ready_for_payment: 1. Visualizar el flujo de trabajo Antes de probar, es increíblemente útil visualizar el gráfico, especialmente con los pesos involucrados. php bin/console workflow:dump expense_approval | dot -Tpng -o workflow.png
 Usted necesita graphviz instalado en su máquina para usar el punto. Si no lo tiene, puede pegar la salida de texto en un visualizador en línea Graphviz. La salida representará visualmente las flechas con etiquetas como peso: 3, haciendo claro que la transición de envío engendra múltiples tokens. Verificación de la unidad (Unit Testing) No solo esperamos que funcione; lo demostramos. cargar la configuración actual del flujo de trabajo y probar las transiciones. 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);
    }
}
 Corre la prueba: php bin/phpunit tests/Workflow/ExpenseApprovalWorkflowTest.php
 Usos avanzados y mejores prácticas Uso de Enums para Lugares (Nuevo en 7.4) Symfony 7.4 también añade soporte para Backed Enums en los flujos de trabajo. “Tienes que definir un enum. 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';
}
 Luego puede actualizar su workflow.yaml (aunque YAML todavía utiliza cadenas, su código PHP puede usar ) de ExpenseState::REVIEW_POOL->value Eventos de Guardia con pesos Usted puede querer evitar lo mismo de la aprobación 3 veces. Las transiciones ponderadas permiten la transición 3 veces, pero el motor de flujo de trabajo no sabe inherentemente quién lo llamó. person approve Para solucionar esto, utilice un escuchador de guardia. #[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 rechazo de la manipulación (Token Cleanup) Uno de los desafíos con los tokens ponderados es la limpieza.Si tenemos 2 aprobaciones y la tercera persona llama ¿Qué sucede con los 2 tokens sentados en ? reject approved_pool En un flujo de trabajo estándar, se Puede dejar esos estragando tokens (creando un estado zombie donde el informe es tanto rechazado como parcialmente aprobado). rejected approved_pool El la transición debe consumir idealmente Sin embargo, el consumo dinámico no se apoya exclusivamente en YAML (no se puede decir “consume TODO”). reject all Usando un suscriptor de evento en , puede reiniciar manualmente la marca de la tienda. workflow.entered.rejected public function onRejected(Event $event): void
{
    $expense = $event->getSubject();
    // Force reset state to ONLY rejected
    $expense->setCurrentState(['rejected' => 1]);
}
 Conclusión Sinfonía 7.4 Al permitir que múltiples instancias de un estado (tokens) existan simultáneamente, ahora podemos modelar sistemas de votación, fabricar líneas de montaje y la lógica de procesamiento de lotes directamente en la configuración, reduciendo drásticamente la cantidad de boilerplate PHP personalizado necesario. Weighted Workflow Transitions Key Takeaways: 
 
 
 
 
 Multiplicidad: Los lugares pueden contener múltiples tokens, permitiendo la acumulación paralela de estado. Configuración: Utilice el peso en sus definiciones de a (salida) y de (entrada) para controlar el flujo de token. Almacenamiento: Asegúrese de que su propiedad de Marking Store sea una matriz (por ejemplo, una columna JSON) para rastrear los números de token por lugar. Verificación: Utilice siempre el comando workflow:dump y escriba las pruebas de KernelTestCase para demostrar su lógica gráfica antes de la implementación. Esta característica solidifica el componente de Workflow de Symfony como la solución de PHP líder para la gestión del estado, lo que le permite eliminar propiedades frágiles y confiar en una arquitectura matemática sólida. Vamos a estar en contacto Adoptar estos patrones avanzados puede simplificar significativamente su lógica de dominio, pero la transición no siempre es obvia.Si usted está buscando modernizar su pila de Symfony, necesita un segundo par de ojos en su arquitectura, o simplemente quiere ver las últimas implementaciones de Petri net, me encantaría escuchar de usted. Contacta conmigo en Linkedin ( ) para continuar la conversación sobre la arquitectura PHP moderna. https://www.linkedin.com/in/matthew-mochalkin/ https://www.linkedin.com/in/matthew-mochalkin/

Read My Stories

Este audio es producido en el idioma original de la historia!

Cómo construir un sistema de aprobación de FinTech con Symfony 7.4

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps