This discussion topic serves as a reference point to capture challenges with the migration to the topic-per-event topology. Please share with us the challenges you faced or rough edges you discovered during the migration.
There is also a github issue you can use should you prefer this avenue.
For cases when specific data or insights of the project needs to be disclosed, feel free to raise a support request.
Other question:
It’s not clear to me from the manual. if we need todo this manual or if the installer takes care of this. I assume the later? topology.SubscribeTo<IOrderStatusChanged>("Shipping.OrderAccepted");
We have not yet made the decision when we’ll upgrade the Functions support. We expect to assess its priority next week.
It’s not clear to me from the manual. if we need todo this manual or if the installer takes care of this. I assume the later?
The topology.SubscribeTo<>() API is used to override the default mapping, which is the event’s full name. In this case if you have a handler for Shipping.IOrderStatusChanged like this:
public class OrderStatusChangedHandler : IHandleMessages<IOrderStatusChanged>
{
}
and auto-subscribe enabled (default), the automatic subscription mechanism will create topic shipping.iorderstatuschanged and a subscription to that topic with forwarding to its input queue. This topic, however, will never receive any messages because publisher always publishes concrete events e.g. OrderAccepted. That events, by default, will be published to shipping.orderaccepted topic.
This why the mapping via topology.SubscribeTo is necessary in this case.
Wanted to give you a heads-up that we are making good progress with the function integration, and we are looking at an ETA of a week(ish) until it is completed if nothing else pops up during our testing.
@SzymonPobiega thanks. I rolled it out today and I will monitor it. I am happy with this change because we have hit the 5Gb limit in the past :-).
When not using interfaces, but concrete classes, do I also need to specify it explicitly?
I have the following msgs:
public record InteractionEvent : IEvent
public record InteractionSent : InteractionEvent
public record InteractionOpened : InteractionEvent
public record InteractionClicked : InteractionEvent
I only published the events derived from InteractionEvent, never the InteractionEvent itself.
I subscribe only to InteractionEvent (for now) in my handler.
I see that only the interactionevent topic is auto created (but not the derived msg types). Will this work ok, or do I need to specify explicit to publish all derived msg to interactionevent?
You need a bit of mapping here. This can be done in two ways.
Subscriber-side
On the subscriber side you can inform the endpoint that, although the type accepted by the handler is InteractionEvent, the actual topics you are interested in are named after the derived types:
With your explanation, it finally clicked for me :-).
Only concrete classes work, inheritance or any interfaces will not auto work, and you need to wire them up yourself. I think adding an example like your explanation to the manual would make it a little bit clearer (the manual doesn’t make it clear enough what does work automatically and what doesn’t).
A third option would be then to not subscribe the handler to the base class, but all the derived classes. Then I don’t need to do the manual wiring (my preference I think).
While you’re at that, it would be valuable to provide a sample of the mapping via configuration, briefly mentioned in the upgrade guide, under more advanced scenarios, but not in the topology document.
I think there is definitely room for improvement on the documentation page. I have already noted down once we have the two other PRs merged, it might be beneficial to go over the pages again to consolidate things a bit.