A súa Permite aos desenvolvedores desconectar a lóxica do proceso empresarial do estado da entidade, transformando os complexos controis de estado de "código spaghetti" en gráficos dirixidos limpos e visualizables. symfony/workflow Durante anos, con todo, o compoñente tivo unha estrita limitación enraizada na súa implementación de redes Petri: Un obxecto estaba nun lugar (estado), ou non estaba.Aínda que podes estar en varios lugares simultaneamente (procesamento paralelo), non podes estar no mesmo lugar varias veces. Tokens were boolean Symfony 7.4 changes the game with Weighted Transitions. Esta nova funcionalidade introduce Agora pode modelar escenarios onde as cantidades importan: "recoller 4 sinaturas", "procesar 5 elementos de lote" ou "esperar que 3 subsistemas se inicien". multiplicity Neste artigo, imos construír unha sólida Imos explorar como configurar transicións ponderadas, implementar a lóxica da entidade e verificar o fluxo con probas rigorosas - todo usando Symfony 7.4 e PHP 8.3. Multi-Signature Approval System O concepto (Petri Nets vs. máquinas estatais) Antes de escribir código, é crucial comprender por que esta característica existe. A limitación da máquina estatal Unha máquina de estado é linear.Un ascensor tamén é , ou Non pode ser Isto é perfecto para estados máis sinxelos (por exemplo, ) da STOPPED MOVING_UP MOVING_DOWN MOVING_UP Order::STATUS_PAID O fluxo de traballo (Petri Net) A unha Permite que un obxecto se sitúe en varios lugares á vez.Nun proceso de "Novo Empregado Onboarding", un empregado pode estar simultaneamente en: Workflow 
 
 
 Proxecto - Laptops Crear unha conta de correo electrónico Ambos deben ser completados antes de que se trasladan a . onboarded A peza que falta: multiplicidade Antes de Symfony 7.4, se necesitabas "3 xestores para aprobar un gasto", non poderías modelalo puramente no fluxo de traballo. 
 
 
 
 Crear unha localización de espera_para_aprobación. Engade un campo de conta á súa entidade ($approvalCount). Utilice un escoitador de eventos Guard para comprobar se ($subject->getApprovalCount() >= 3) antes de permitir a transición. con O “ O motor de fluxo de traballo entende nativamente que o suxeito está no estado de fluxo de traballo. Estado 3 veces. Weighted Transitions counter approved Proxecto Setup Imos crear un novo proxecto Symfony e instalar os compoñentes 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 exemplo, usaremos SQLite para a simplicidade, pero a lóxica aplícase a MySQL / PostgreSQL exactamente o mesmo. # .env
DATABASE_URL="sqlite:///%kernel.project_dir%/var/data.db"
 Configuración (a lóxica básica) Definiremos un fluxo de traballo chamado expense_approval. The Scenario: 
 
 
 
 
 
 Realízase un informe de gastos (proxecto). A súa presentación é necesaria (review_required) O paso ponderado: O sistema distribúe a solicitude a 3 aprobadores necesarios. Cada aprobador outorga a aprobación individualmente. Unha vez que se recollen 3 aprobacións, o gasto móvese a ready_for_payment. Crear ou 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
 Desconstruíndo o Config 
 
 
 
 
 tipo: fluxo de traballo: As transicións ponderadas dependen de buckets de token. Isto non é posible nunha máquina de estado. submitTransition:- a: {lugar: review_pool, peso: 3 } - Cando este lume, thereview_poolplace recibe 3 tokens.- Pense isto como crear3 "ticket" que precisa ser golpeado. aprobarTransition:-de: review_pool, a: approved_pool.- Peso estándar 1-to-1.- Porque temos 3 tokens inreview_pool, podemos disparar esta transición 3 veces. finalizeTransition:- de: {lugar: aprobado_pool, peso: 3 }- Esta transición está bloqueada ata que o aprobado_pool conteña exactamente (ou polo menos) 3 tokens.- Unha vez que entra a 3a aprobación, este camiño desbloquea. A entidade Necesitamos unha entidade que apoie esta tenda de marcación "Multi-State". A propiedade debe ser unha matriz para manter as contas de token (por exemplo, ) da 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;
    }
}
 Xestionar a migración: php bin/console make:migration
php bin/console doctrine:migrations:migrate
 Servizo Layer Este servizo manexará a lóxica de "quen" está aprobando, aínda que para este tutorial, centrarémonos na mecánica do fluxo de traballo. 
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');
    }
}
 A lóxica de “auto-finalizar” Observe o método de aprobación.Despois de aplicar aprobar, inmediatamente comprobamos que pode ($expense, ‘finalizar’). 
 
 
 
 Primeira aprobación:-review_pool: 2-approved_pool: 1-finalize needs 3 approved_pool. can(‘finalize’) devolve false. SecondApproval:-review_pool: 1-approved_pool: 2-can(‘finalize’) devolve falso. ThirdApproval:review_pool: 0approved_pool: 3finalize needs 3. can(‘finalize’) devolve true.We applyfinalize.New State:ready_for_payment: 1. Visualizar o fluxo de traballo Antes de probar, é incrible útil visualizar o gráfico, especialmente con pesos implicados. php bin/console workflow:dump expense_approval | dot -Tpng -o workflow.png
 Necesitas graphviz instalado na túa máquina para usar o punto.Se non o tes, podes pegar a saída de texto nun visualizador de Graphviz en liña. A saída representará visualmente as frechas con etiquetas como peso: 3, deixando claro que a transición de envío dá lugar a múltiples tokens. Proba de unidade (Unit Testing) Non só esperamos que funcione; demostrámolo. Cargar a configuración actual do fluxo de traballo e probar as transicións. 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 a proba: php bin/phpunit tests/Workflow/ExpenseApprovalWorkflowTest.php
 Aplicacións avanzadas e mellores prácticas Usando Enums para Lugares (Novo en 7.4) Symfony 7.4 tamén engade soporte para Enums de copia de seguridade nos fluxos de traballo. “Hai que poñer un enunciado. 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ón, pode actualizar o seu workflow.yaml (aínda que YAML aínda usa cadeas, o seu código PHP pode usar ) da ExpenseState::REVIEW_POOL->value Eventos de garda con pesos Quizais quere evitar o mesmo de aprobación 3 veces. Transicións ponderadas permiten a transición 3 veces, pero o motor de fluxo de traballo non sabe inherentemente quen o chamou. person approve Para solucionar isto, use un escoitador de garda. #[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.');
    }
}
 Rexeitamento de manexo (limpeza de token) Un desafío con tokens ponderados é a limpeza. Se temos 2 aprobacións e a terceira persoa chama , o que pasa cos 2 tokens sentados en ? reject approved_pool nun fluxo de traballo estándar, moverse a podería deixar os tokens estragando (creando un estado de zombies onde o informe é tanto rexeitado como parcialmente aprobado). rejected approved_pool A súa a transición debería consumir idealmente Con todo, o consumo dinámico non é soportado exclusivamente en YAML (non se pode dicir "consume TODO"). reject all Usando un Subscriptor de eventos en , pode reiniciar manualmente a tenda de marcaxe. 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 Ao permitir que múltiples instancias dun estado (tokens) existan simultaneamente, agora podemos modelar sistemas de votación, fabricar liñas de montaxe e lóxica de procesamento de lotes directamente na configuración, reducindo drasticamente a cantidade de boilerplate PHP personalizado necesario. Weighted Workflow Transitions Key Takeaways: 
 
 
 
 
 Multiplicidade: os lugares poden ter múltiplos tokens, permitindo a acumulación paralela de estado. Configuración: Use o peso nas definicións de to (output) e from (input) para controlar o fluxo de token. Almacenamento: Asegúrese de que a súa propiedade Marking Store é unha matriz (por exemplo, unha columna JSON) para rastrexar o número de tokens por lugar. Verificación: Sempre utilice o comando workflow:dump e escriba as probas KernelTestCase para probar a súa lóxica gráfica antes da implantación. Esta característica solidifica o compoñente de Workflow de Symfony como a solución de PHP líder para a xestión de estado, permitíndolle eliminar propiedades fráxiles e confiar nunha arquitectura matemática sólida. Imos estar en contacto Adoptar estes patróns avanzados pode simplificar significativamente a súa lóxica de dominio, pero a transición non sempre é obvia. Se está a buscar modernizar a súa pila de sinfonía, necesita un segundo par de ollos na súa arquitectura, ou só quere gañar as últimas implementacións da rede Petri, gustaríame escoitar de vostede. Podes contactar connosco en Linkedin ( ) para continuar a conversación sobre a arquitectura PHP moderna. https://www.linkedin.com/in/matthew-mochalkin/ https://www.linkedin.com/in/matthew-mochalkin/

Read My Stories

Este audio está producido na lingua orixinal da historia!

Aquí está como pode construír un sistema de aprobación FinTech con Symfony 7.4

About Author

COMENTARIOS

Etiquetas colgantes

ESTE ARTIGO FOI PRESENTADO EN

Related Stories

Coñece R Systems: HackerNoon empresa da semana

R Systems BlogBook—Chapter 1: Round 3 is Now Open for Submissions🎉

HackerNoon Decoded 2024: Celebrating Our Life Hacking Community!

HackerNoon Decoded 2024: Celebrating Our Tech Stories Community!

Coñece R Systems: HackerNoon empresa da semana

R Systems BlogBook—Chapter 1: Round 3 is Now Open for Submissions🎉

HackerNoon Decoded 2024: Celebrating Our Life Hacking Community!

HackerNoon Decoded 2024: Celebrating Our Tech Stories Community!

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps