Événements
Vavang Invoice expose actuellement un événement applicatif dans le flux initial de conformité : SyliusInvoicePlugin\Invoice\InvoiceCreated.
Transport
L’événement est publié sur sylius.event_bus, injecté comme MessageBusInterface Symfony Messenger. Il n’est pas publié via le EventDispatcherInterface Symfony.
Le message contient :
SourceInvoiceReference, qui identifie la facture Sylius source ;ActionOrigin, qui précise si l’action provient du système ou d’une autre origine supportée.
N’enregistrez donc pas un subscriber Symfony classique en espérant recevoir cette classe comme un événement kernel/domain. Consommez-la comme un message sur le bus d’événements Sylius.
Exemple de handler
<?php
declare(strict_types=1);
namespace App\Invoice;
use SyliusInvoicePlugin\Invoice\InvoiceCreated;
final class OnInvoiceCreated
{
public function __invoke(InvoiceCreated $event): void
{
$sourceInvoice = $event->sourceInvoice();
$origin = $event->origin();
// Déclenchez ici les effets de bord propres au projet sans muter la facture source.
}
}
# config/services.yaml
services:
App\Invoice\OnInvoiceCreated:
tags:
- { name: messenger.message_handler, bus: sylius.event_bus }
Portée
InvoiceCreated signale l’entrée dans le traitement initial de conformité. Ce n’est pas une notification générique pour chaque changement d’état ultérieur, résultat de validation, résultat de transmission ou opération d’avoir.
Si l’événement dont vous avez besoin n’existe pas, ne couplez pas le code applicatif à un listener Doctrine interne ou à une classe d’implémentation privée. Ouvrez une demande d’extension ou utilisez un décorateur de service documenté quand cela correspond au besoin.
Risque de BC
La classe de message et ses accesseurs constituent une frontière d’intégration plus sûre que le dispatcher concret ou le listener Doctrine qui l’émet aujourd’hui. Considérez les listeners internes et les constructeurs des dispatchers comme des détails d’implémentation.