We have an environment for three instances of BizTalk 2016 that are used randomly by the messages.
I would need to know which one has been used when I send a message, but only if it has had any error and it is shown in the Windows logs-->Application is said which computer was used.
But I'd need to know which computer was used when the message was fine, but in the 'Tracked Message Events' this information is not shown and the flow of the message is displayed in the three instances.
Any idea of how I could get this information?
The fact of the matter is that it could be anyone of the three servers within your BizTalk Group. What you could do is track the properties and in the send pipeline promote the machine name. Although I'm not sure why you would need to do this.
Please remember that a send port can be triggered by any server with a particular host instance configured and running and that retry attempts may even be done on other server(s) as long as the triggered host instance is running there.
Related
My question is two-fold:
First, in Redis, is it possible to have multiple publishers to publish messages to the same channel?
And second, if the answer to the first part is yes (which I think it is), is it possible to tell (on the subscriber end) which publisher has sent any given message?
My scenario is that I've got a server which sends events to Redis right now. And I would like to have multiple instances of it and collect all their events. I was wondering if it is possible to centralize their events in one Redis while being able to tell apart the message sources without changing the publisher code. I mean one solution is to have each server include some ID in the message but that requires changing the code which I prefer not to do.
First, in Redis, is it possible to have multiple publishers to publish messages to the same channel?
Yes. You can even easily test it!
And second, if the answer to the first part is yes ...
The message doesn't include the publisher, but the publisher can add its name to the message explicitly. For that you'd have to change the actual code that calls PUBLISH from your application - no two ways about it.
I have a notification service that handles events and publishes them to clients using various technologies, such as SignalR. I want every instance of my notification service to pick up and handle these events. However, NServiceBus only allows any one instance of my notification service endpoint to pick up the event, and the other instances never get it.
My current workaround for this is to create a separate named endpoint for each instance of my notification service (the name has the server host name added to it), but then I have to make sure I unsubscribe from the event when the instance goes down or is moved to another server.
Is there a better way to do this? It would be nice if I could configure NServiceBus to create a separate incoming queue for each endpoint instance in this case, but I can't figure out how to do that, or even if NServiceBus supports such a use case.
You are correct. NServiceBus does not support such a case. Subscribers are always treated as logical endpoints, so individualized queues would not be used even if they were available.
Differentiating the instances by modifying the endpoint name is the most straightforward way to achieve what you want.
Changing your differentiator to a controllable runtime value, for instance an environment variable, would at least alleviate the need to unsubscribe when an instance is moved.
Also, if you want to review the scenario in more detail please don't hesitate to reach out to us directly, we might have other approaches to suggest. Just open a support ticket.
I'm new to NServiceBus, but currently using it with SQL Server Transport to send messages between three machines: one belongs to an endpoint called Server, and two belong to an endpoint called Agent. This is working as expected, with messages sent to the Agent endpoint distributed to one of the two machines via the default round-robin.
I now want to add a new endpoint called PriorityAgent with a different queue and two additional machines. While all endpoints use the same message type, I know where each message should be handled prior to sending it, so normally I can just choose the correct destination endpoint and the message will be processed accordingly.
However, I need to build in a special case: if all machines on the PriorityAgent endpoint are currently down, messages that ordinarily should be sent there should be sent to the Agent endpoint instead, so they can be processed without delay. On the other hand, if all machines on the Agent endpoint are currently down, any Agent messages should not be sent to PriorityAgent, they can simply wait for an Agent machine to return.
I've been researching the proper way to implement this, and haven't seen many results. I imagine this isn't an unheard-of scenario, so my assumption is that I'm searching for the wrong things or thinking about this problem in the wrong way. Still, I came up with a couple potential solutions:
Separately track heartbeats of PriorityAgent machines, and add a mutator or behavior to change the destination of outgoing PriorityAgent messages to the Agent endpoint if those heartbeats stop.
Give PriorityAgent messages a short expiration, and somehow handle the expiration to redirect messages to the Agent endpoint. I'm not sure if this is actually possible.
Is one of these solutions on the right track, or am I off-base entirely?
You have not seen many do this because it's considered an antipattern. Or rather one of two antipatterns.
1) Either you are sending a command, in which case the RECEIVER of the command defines the contract. Why are you sending a command defined by PriorityAgent to Agent? There should be no coupling there. A command belongs to ONE logical endpoint/queue.
2) Or you are publishing an event defined by whoever publishes, with both PriorityAgent and Agent as subscribers. The two subscribers should be 100% autonomous and share nothing. Checking heartbeats/sharing info between these two logical separate entities is a bad thing. Why have them separately in the first place then? If they know about each other "dirty secrets," they should be the same thing.
If your primary concern is that the PriorityAgent messages will not be handled if the machines hosting it are down, and want to use the machines hosting Agent as a backup, simply deploy PriorityAgent there as well. One machine can run more than one endpoint just fine.
That way you can leverage the additional machines, but don't have to get dirty with sending the same command to a different logical endpoint or coupling two different logical endpoints together through some back channel.
I'm Dennis van der Stelt and I work for Particular Software, makers of NServiceBus.
From what I understand, both PriorityAgent and Agent are already scaled out over multiple machines? Then they both work according to competing consumers pattern. In other words, both machines try to pick up messages from the same queue, where only one will win and starts processing the message.
You're also talking about high availability. So when PriorityAgent goes down, another machine will pick it up. That's what I don't understand. Why fail over to Agent, which seems to me to be a logically different endpoint? If it is logically different, how can it handle PriorityAgent messages? If it can handle the same message, it seems logically the same endpoint. Then why make the difference between PriorityAgent and Agent?
Besides that, SQL Server has all kinds of features (like Always-On) to make sure it does not (completely) go down. Why try to solve difficult scenarios with custom build solutions, when SQL Server can already solve this for you?
Another scenario could be that PriorityAgent should handle priority cases. Something like preferred customers, or high-value customers. That is sometimes used when (for example) a lot of orders (read: messages) come in, but we want to deal with high-value customers sooner than regular customers. But due to the amount of messages coming in, high-value customers would also end up in the back of the queue, together with regular customers. A solution could be to publish these messages and have two different endpoints (with different queues) subscribed both to this message. Both receive each unique message, but check whether it's a message they should handle. The Agent will ignore high-value customers, the PriorityAgent will ignore regular customer.
These are some of the solutions available as standard messaging patterns, or infrastructural solutions to solving your issue. Again, it's not completely clear to me what it is you're looking for. If you'd like to continue the discussion; perhaps you want to email support#particular.net and we can continue the discussion there.
I try to implement another DiscoveryAgent using a kind of database. I find this code and it helps me to understand how the DiscoveryAgent works :
https://github.com/sliard/multicastdb
But I don't know when the method registerService is called. When I changed the code of the multicast DiscoveryAgent to see when it's called, but it isn't when the DiscoveryAgent starts. But if it's not called, the broker can't advertize itself to the database...
Then I don't understand how a broker can communicate with another using the information of a DiscoveryAgent.
So if you can explain me when this method is called and if you have some documentation on the implementation of a DiscoveryAgent, it would be great.
Thanks in advance.
The registerService method is called from the Broker's TransportConnector when it is started which is at a different time from the start of the agent. You should take some time to look at the code of the various agents in ActiveMQ. The multicast version and the HTTP agent are good examples.
Keep in mind that the agents are written for both the Broker and the Client code to use so there is some code that isn't run from the Broker side and some that's not used on the client end. If you want to implement only a client side agent then you don't need to worry about the registration or advertisement bits, but if you want the broker to add itself to your DB implementation you would want to implement those bits so that the broker can add itself and do whatever your advertisement mechanism is.
The source code and test are your best documentation. Look at the code, run the tests and set breakpoints to see what's going on. You can even build from source and add in your own Logging if need be to get a better feel for it.
I'm trying to set up a client-server architecture. I have one GKSession configured as a server, and two others as clients.
When either client uses the sendData:toAllPeers:WithDataMode:error method, it sends it not only to the server but to the other client.
I guess I could use the display name to exclude clients, so client data only goes to the server, but I'm not quite following why this is happening.
My server explicitly accepts a connection, via acceptConnectionFromPeer:error: But my client isn't accepting anything from anybody, it seems to be just silently finding the other client.
Should this be happening? I understand in a peer-peer setup you'd want peers to just find others; but in client-server, this seems a little weird.
Any clarification or advice would be greatly appreciated.
While a client cannot explicitly connect to another client, but the method sendData:toPeers:withDataMode:error: should allows you to send data directly from one client to another given that you have the correct peerId.