This was a deep dive, thanks for the video Chris. At 3:18, why are there two separate new blocks both including the registrationid and why would the participantemailaddress be here? Is that not already available in the routing slip as a variable? I see why you would want to get the Amount and registrationid added to the variables, but that first block is a bit confusing. Thanks!
The first block (lines 39-42) are for the compensation log, which saves the registrationId and the email address of the registered racer. The second block (lines 43-47) are variables added to the routing slip (by name, case doesn't matter as the dictionaries are case-insenstive).
@@PhatBoyG Gotcha, that makes sense. I did not realize one of the activities in the sample was execute only and does not compensate. I guess I would have expected the order to be reversed here, but I probably need to look at the way ExecutionResult is written.
Hello, must the subscription to the event emitted by the routing slip be done using saga state machine or are there other mechanisms to subscribe to routing slip events? Thank you.
masstransit.io/documentation/patterns/routing-slip#subscriptions Subscriptions can be used to send routing slip events to any consumer type (saga, consumer, etc.).
Hi Chris, thanks for creating MassTransit and for taking time to do these videos. I have a doubt about Activities. Shouldn't each activity be on a different Project/Process/Service? If that is the case, How could you register those activities that are in different Project/Process/Service?
Adding activities to a routing slip does not require the activity be available to that assembly. It's all based upon the execute address of the activity, which is simply a URI. The activity arguments are passed as a dictionary, no coupling at all to the argument type.
This was a deep dive, thanks for the video Chris. At 3:18, why are there two separate new blocks both including the registrationid and why would the participantemailaddress be here? Is that not already available in the routing slip as a variable? I see why you would want to get the Amount and registrationid added to the variables, but that first block is a bit confusing. Thanks!
The first block (lines 39-42) are for the compensation log, which saves the registrationId and the email address of the registered racer.
The second block (lines 43-47) are variables added to the routing slip (by name, case doesn't matter as the dictionaries are case-insenstive).
@@PhatBoyG Gotcha, that makes sense. I did not realize one of the activities in the sample was execute only and does not compensate. I guess I would have expected the order to be reversed here, but I probably need to look at the way ExecutionResult is written.
Hello, must the subscription to the event emitted by the routing slip be done using saga state machine or are there other mechanisms to subscribe to routing slip events? Thank you.
masstransit.io/documentation/patterns/routing-slip#subscriptions
Subscriptions can be used to send routing slip events to any consumer type (saga, consumer, etc.).
@@PhatBoyG Thank you, love this library
Hi Chris, thanks for creating MassTransit and for taking time to do these videos. I have a doubt about Activities. Shouldn't each activity be on a different Project/Process/Service? If that is the case, How could you register those activities that are in different Project/Process/Service?
Adding activities to a routing slip does not require the activity be available to that assembly. It's all based upon the execute address of the activity, which is simply a URI. The activity arguments are passed as a dictionary, no coupling at all to the argument type.