Do any of you use Axon framework with custom bus instead of Axon server?
I would like to use Axon framework with custom message bus. Unfortunately I could not see anything in their documentation.
Hi #RamPrakash you can find the documentation about the distributed command bus here: https://docs.axoniq.io/reference-guide/axon-framework/axon-framework-commands/infrastructure#the-command-bus-distributed and about the event store here: https://docs.axoniq.io/reference-guide/axon-framework/events/event-bus-and-event-store
Related
I want to publish an event through one of my aggregate event handlers to the axon Kafka topic as I am using kafka as my event bus. What is the correct way to do that? Should I directly push the message to the topic or can I use AggregateLifecycle#apply(event) in this case?
I have multiple events getting published from my aggregate, through one of the event handlers I want to publish another event. I am using axon 4.2
Easiest would be to start using the Kafka Extension Axon provides. The shared repository contains all the necessary code to create a publishing end and a consuming end of Axon Event from and to a Kafka topic. For configuration convenience, there is a Spring Boot Starter present in that project too
Added, the repository has a (Kotlin) sample project showing how to configure it, which you can find here. Lastly, for a full description of how to set everything up, I strongly recommend to give Axon's Reference Guide a read, especially the Kafka page here.
I'd like to recommend you thought that this extension is perfectly suited to communicate between Axon and non-Axon applications, making Kafka a form of "Enterprise Service Bus". Using it as the EventBus replacement within Axon Framework is doable, but requires a bunch of fine tuning on you rend. It would be wiser to use Axon Server instead in those scenarios, or if you really must, share the data source containing your events directly between the applications.
I would like to understand an Axon feature.
Currently, we are developing an application using microservice architecture.
We want to store all service events in a central RDBMS database, like for example PostgreSQL.
Is it possible to use such a store?
We have used the below configuration to store events in same domain DB:
#Bean
public AggregateFactory<UserAggregate> userAggregateFactory() {
SpringPrototypeAggregateFactory<UserAggregate> aggregateFactory =
new SpringPrototypeAggregateFactory<>();
aggregateFactory.setPrototypeBeanName("userAggregate");
return aggregateFactory;
}
Now we want to store events in a central Event Store DB, not with domain DB.
Firstly, the AggregateFactory within any Axon application does not define where or how your events are stored at all.
I instead suggest to read the Event Bus & Event Store section of the Axon Framework reference guide on the matter to explain how you can achieve this.
The short answer to your question is by the way yes, you can have a single Event Store backed by a RDBMS, like PostgreSQL, to store all your events in.
Between duplicated instances of a given application it is actually highly recommended to use the same storage location.
As soon as you are going to span different Bounded Context's, I would suggest to define different Event Stores per context though.
Concluding, you are using an old version of Axon Framework.
I would highly recommend to move the at least the latest Axon 3 release, being 3.4.3, but ideally you start using 4.1.2.
Note that there is no active development taking place on Axon 3 any more, hence the suggestion.
I'm using Axon version (3.3) which seamlessly supports Kafka with annotation in the SpringBoot Main class using
#SpringBootApplication(exclude = KafkaAutoConfiguration.class)
In our use case, the command side microservice need to pick message from kafka topic rather than we expose it as Rest api. It will store the event in event store and then move it to another kafka topic for query side microservice to consume.
Since KafkaAutoCOnfiguration is disabled, I cannot use spring-kafka configuration to write a consumer. How can I consume a normal message in Axon?
I tried writing a normal Kafka spring Consumer but since Kafka Auto COnfiguration is disabled, initial trigger for the command is not picked up from the Kafka topic
I think I can help you out with this.
The Axon Kafka Extension is solely meant for Events.
Thus, it is not intended to dispatch Commands or Queries from one node to another.
This is very intentionally, as Event messages have different routing needs apposed to Command and Query messages.
Axon views Kafka a fine fit as an Event Bus and as such this is supported through the framework.
It is however not ideal for Command messages (should be routed to a single handler, always) or Query messages (can be routed to a single handler, several handlers or have a subscription model).
Thus, I you'd want to "abuse" Kafka for different types of messages in conjunction with Axon, you will have to write your own component/service for it.
I would however stick to the messaging paradigm and separate these concerns.
For far increasing simplicity when routing messages between Axon applications, I'd highly recommend trying out Axon Server.
Additionally, here you can hear/see Allard Buijze point out the different routing needs per message type (thus the reason why Axon's Kafka Extension only deals with Event messages).
Now I'm using service bus topic as a backplane for signalr. But event hub is much cheaper than topics. Therefore, I want use Event Hub as a backplane for SignalR.
Can I do this now or in near feature ?
Not sure this is a real answer, but it looks like to me. I am not sure whether Event Hub is suitable for your goal, but assuming you verified and it is, then you can write your own backplane supporting it. For exercise I wrote one which was using SignalR itself (doh) as a backplane system and it was not damn difficult. You can take inspiration from the source code of the one for Service Bus and roll out your own. In particular you'll have to put most of your logic when implementing your version of a ScaleoutMessageBus-derived class.
Using the BizTalk ESB Toolkit 2.0
We are working on a project where we need to call a proxy to a web service which is a DLL. We have no problems doing this via an orchestration since you can use a static port and configure it to use the SOAP adapter with the web service setting pointing at the assembly in the BizTalk Admin interface. In the itinerary though there doesn't seem to be an obvious way to do this since dynamic ports don't have the option to use the SOAP adapter.
There is a good reason why we want to do this, don't worry.
Following on from this, we implemented a custom adaptor provider but are having problems getting it to work.
We followed an (old) example shown here:
The custom adaptor provider inherits from BaseAdapterProvider and overrides the SetEndPoint(Dictionary, IBaseMessageContext) method.
The method extracts the assembly name, type name, and method name that are passed in via the resolver dictionary and then writes them to the pipeline context:
pipelineContext.Write("TypeName",
"http://schemas.microsoft.com/BizTalk/2003/soap-properties", typeName);
pipelineContext.Write("MethodName",
"http://schemas.microsoft.com/BizTalk/2003/soap-properties", action);
pipelineContext.Write("AssemblyName",
"http://schemas.microsoft.com/BizTalk/2003/soap-properties", assembly);
and sets the transport type to soap:
pipelineContext.Write("TransportType",
"http://schemas.microsoft.biztalk.practices.esb.com/itinerary", "SOAP");
In all other respects the adapter provider is nearly identical to the example shown in the link above, except for the obvious change from SMTP to SOAP.
The adapter provider assembly is signed, GACed, and added to the esb.config.
The adapter provider is called from an itinerary that only calls the service and then returns the response. We are testing the itinerary from the Itinerary Test Client that is shipped with the toolkit. Event logging within the custom adapter shows that the adapter code is being called. The problem is that the message is not being routed to the service proxy. The event viewer gives the following error:
The Messaging engine failed to process
a message submitted by adapter:SOAP
Source
URL:/ESB.ItineraryServices.Response/ProcessItinerary.asmx.
Details:The published message could
not be routed because no subscribers
were found. This error occurs if the
subscribing orchestration or send port
has not been enlisted, or if some of
the message properties necessary for
subscription evaluation have not been
promoted. Please use the Biztalk
Administration console to troubleshoot
this failure.
Investigating the suspended service instamces in Group Overview shows two things:
The values for assembly name, type name, and method name are being set correctly.
The message body is missing.
We have tried configuring the send and receive pipelines on the send port to be both XMLTransmit/XMLReceive and ItinerarySendPassthrough/PassthroughReceive and it makes no difference.
Is there something obvious we might have missed? Do you have to explicitly pass the message body through? If so how?
EDIT:
Following a request from the BizTalk ESB Toolkit forum I am posting screen shots of the itinerary, context and send port filters.
Itinerary,
Context,
Port filters.
Many thanks, Nigel.
first of all I'll say you are trying to over engineer the solution. Adapter development is not trivial and there are various things you need to take in to consideration. Developing and Deploying adapters are categorized as platform changes, which effects your whole environment, so if you are not familiar then your shouldn't do it. I would recommend you taking some other route. At this point I personally don't have enough insight into ESB internals, so won't be able to comment on it. At worst case you may be better off using the .NET proxy dll directly inside your orchestration (expression or message shape) rather than building an adapter. Even though its not recommended approach, still I feel its better than custom adapter approach.
Semantically, I don't see why a solution that involves a WCF-BasicHtpp adapter would not work in your scenario. In any case, I would definitely try to see what happens with a WCF-BasicHttp adapter, and once I got a working solution, I would switch to a custom SOAP adapter if that is really necessary.
Currently, your solution is weird - in the sense that you have an On-Ramp directly connected to an Off-Ramp. I've never seen that in any of my itineraries. You might need to create an intermediate messaging or orchestration Itinerary service in betweeen.
Otherwise, the message effectively gets published to the message box and obviously there is no subscribers for it, hence the error you encounter.