Support chat for http://getprooph.org/ - official announcement: https://www.sasaprolic.com/2018/08/the-future-of-prooph-components.html
If this is not a config issue by the recipe maybe my dependencies don't fit.
"prooph/event-sourcing": "^5.2",
"prooph/event-store-bus-bridge": "^3.0",
"prooph/event-store-symfony-bundle": "dev-master",
"prooph/pdo-event-store": "^1.0",
"prooph/service-bus-symfony-bundle": "dev-master",
"react/promise": "^2.7.1",
No, seems to be fine.
I'll have a look at what you're mentioning tomorrow :)
BTW could be related to this: https://github.com/prooph/pdo-event-store/issues/39#issuecomment-275074549
Hi @webdevilopers, The TransactionManager plugin is only compatible with the PostgresEventStore indeed. We should not define this plugin in the recipe as the preconfigured event store relies on the MySqlEventStore impl. I will fix that. Please remove this configuration from your
prooph_event_store_bus_bridge.yaml file.
Thanks for the report :+1:
Great work, thanks! I had to setup the project very quickly. That's why I started with Symfony 5 which was then incomatible to some dependencies I copied from an older Symfony 4 project.
Symfony is really releasing quickly. Even 6 months old projects sometimes fail when copying the dependencies. A lot of configuration has to be done from scratch or accidentally mix up with the existing.
But I'm happy some contributors are still interested in keeping the Prooph <=> Symfony connection alive.
Symfony is really releasing quickly. Even 6 months old projects sometimes fail when copying the dependencies. A lot of configuration has to be done from scratch or accidentally mix up with the existing.
But I'm happy some contributors are still interested in keeping the Prooph <=> Symfony connection alive.
I thought it might be related to sebastianbergmann/phpunit#3728 or mockery/mockery#981
But then I should get the same errors locally
Here's the full build result: https://travis-ci.org/prooph/pdo-event-store/jobs/623131023#L501
Contacting Travis support to enable debug mode might help (https://docs.travis-ci.com/user/running-build-in-debug-mode/#enabling-debug-mode), but I most likely don't have the correct permission
I'm currently trying to implement a process manager. The events are published but the manager is not called.
event_store_bus_bridge from recipe:services:
_defaults:
public: false
Prooph\EventStoreBusBridge\EventPublisher:
public: true
arguments:
- '@prooph_service_bus.default_event_bus'
tags:
- { name: 'prooph_event_store.default.plugin' }
The
services:services:
# default configuration for services in *this* file
_defaults:
autowire: true # Automatically injects dependencies in your services.
Acme\Claims\Infrastructure\ProcessManager\ClaimDelegation:
public: true
arguments: ['@prooph_service_bus.default_command_bus']
And the
prooph_service_bus.yaml:prooph_service_bus:
command_buses:
default_command_bus:
router:
type: 'prooph_service_bus.command_bus_router'
routes:
'Acme\Claims\Application\Service\RegisterClaim': 'Acme\Claims\Application\Service\RegisterClaimHandler'
event_buses:
default_event_bus:
plugins:
- 'prooph_service_bus.on_event_invoke_strategy'
router:
type: 'prooph_service_bus.event_bus_router'
routes:
'Acme\Claims\Domain\Claim\Event\ClaimRegistered':
- 'Acme\Claims\Infrastructure\ProcessManager\ClaimDelegation'
The process manager exists correctly:
final class ClaimDelegation
{
public function __invoke(ClaimDelegated $event): void
{
dump($event);exit;
}
}
Any idea what is missing?
@prolic Thanks for the answer, so it seems I'm missing something:
I took a look at some prooph code e.g. the Message Bus that is used as Event Bus:
abstract class MessageBus
{
public function __construct(ActionEventEmitter $actionEventEmitter = null)
{dump($actionEventEmitter);
if (null === $actionEventEmitter) {
$actionEventEmitter = new ProophActionEventEmitter([
self::EVENT_DISPATCH,
self::EVENT_FINALIZE,
]);
}The emitter is null here. Maybe this is the a hint.
I also corrected the tags of the event publisher in order to use my claim_store:
prooph_event_store:
stores:
claim_store:
event_store: 'app.event_store.default'
repositories: Prooph\EventStoreBusBridge\EventPublisher:
public: true
arguments:
- '@prooph_service_bus.default_event_bus'
tags:
- { name: 'prooph_event_store.claim_store.plugin' }The symfony recipe default was:
#- { name: 'prooph_event_store.default.plugin' }
Though it wonders me because the proophessor demo seems to work with it:
services:
# default configuration for services in *this* file
_defaults:
# automatically injects dependencies in your services
autowire: true
# automatically registers your services as commands, event subscribers, etc.
autoconfigure: trueAfter renaming everything and copying composer it seems to work. Really hard to tell what the original issue was.
I will slowly re-add the symfony recipe default values.
In between:
Shouldn't process managers be able to react to multiple events similar to "Sagas"? With "invoke" only one method is possible. What plugin has to be used to allow the multiple "onEvent..." handlers?
@webdevilopers I would suggest checking the actual compiled container to see whereas your process manager is registered in the event bus or not. Are you working on a fresh project? If so you should limit your prooph library to the prooph/pdo-event-store which will have support in the (near) future. I would suggest having a look at this project (although it doesn't have an event bus, as it doesn't need it) which uses Symfony 4.4 and prooph/event-store (with the eventstore tcp client): https://github.com/gquemener/PhpMyOssContrib
Shouldn't process managers be able to react to multiple events similar to "Sagas"? With "invoke" only one method is possible. What plugin has to be used to allow the multiple "onEvent..." handlers?
You still can do it with private methods:
public function __invoke(/** not sure about the type hint */ $message): void
{
switch(get_class($message)) {
case MyEvent::class:
$this->onMyEvent($message);
break;
case MyOtherEvent::class:
$this->onMyOtherEvent($message);
break;
//......
}
}
However, in prooph/service-bus, the method to call is resolve through an
InvokeStrategy plugin: https://github.com/prooph/service-bus/tree/master/src/Plugin/InvokeStrategy
Please note, that AFAIK, this will only change the one method name which is called and will not allow you to have multiple public methods for your process manager (for that you will need to use another event bus, like your own => https://github.com/gquemener/TransportTycoon/blob/master/src/ServiceBus/SimpleEventBus.php)
Thanks for the explanations! I will take a deeper look.
Glad to hear that the PDO Event Store will be continued. Does this include the Event Publisher? Or will I have to glue it together somehow?
Prooph mentioned to suggest blueprints for Event Sourcing solutions with clean Domain models. Looking forward to that!
BTW the question about process managers was also meant in general. On our older application we used these "event listeners" as Sagas that would listen to events and fire new commands in order to orchestrate "long running processes".