Ì have a setup where I have a chain of servers that I need to send messages between:
A -> B -> C
On A I have an application which puts a message on a local MSMQ queue (MSMQ-A) on A. This queue needs to forward the message to a MSMQ queue on B (MSMQ-B) which in turn should forward the message to a MSMQ queue on C (MSMQ-C). On C there is an application which listens to messages from MSMQ-C.
The messages do not need to be transactional.
How do I configure MSMQ-A and MSMQ-B for forwarding of messages?
UPDATE
Based on the suggested answer I have done this:
I've enabled HTTP support under the Windows Message Queuing feature.
I've added a mapping file under the System32/msmq/mappings folder looking like this:
<redirections xmlns="msmq-queue-redirections.xml">
<redirection>
<from>http://machineA/msmsq/private$/logger</from>
<to>http://machineB/msmq/private$/logger</to>
</redirection>
</redirections>
and still the messages get stuck on machineA.
I am using powershell to send the messages to the queue on A like this: Get-MsmqQueue -name logger | Send-MsmqQueue -body "asdasd"
The design you are describing is not something that MSMQ provides.
MSMQ delivers a message from sender to receiver and that's it. You can't have a chain where the receiver automatically becomes the sender to the next receiver. You would need to write an application on each machine that receives the message from the queue and creates a NEW copy of it to send to the next.
MSMQ routing is a different concept. Compare it to parcel shipping where a parcel is routed through different depots across the country until it reaches the final destination. Each depot does nothing with the parcel except to pass it on. They don't open up the parcel, use the contents, and then repackage to send to the next depot.
You may instead be wanted to redirect MSMQ messages. For example, if A is an Internet-based PC, B is an Internet-facing server and C is a PC on an internal LAN (and you want to send A->B->C). If you have that sort of scenario then you need to look at Redirections.
Delivering Messages Sent over the Internet
HTTP Message Redirection
Related
I am using Kamailio 4.4 as the proxy with my Asterisk server. I am trying to develop a scenario where an extension gets registered on asterisk via Kamailio when it receives a push notification. This push notification is sent to the sip extension when a call towards this extension reaches to the Kamailio.
For example, suppose there is two SIP extension( extension 1 and extension 2) registered on Asterisk via Kamailio. When a call from extension 1 reaches the asterisk, it forwards the INVITE request towards extension 2 via Kamailio.Kamailio will try to forward it to extension 2. suppose the extension 2 is not able to receive the INVITE request from Kamailio. When extension two receive a push notification, it will register on asterisk.
So I need to get the call on extension 2 through the new registration.
We are trying to simulate registration of extension to the asterisk when receiving the push notification.
First, we registered extension 2 and disconnected the network. Then we tried to register the same extension when a call from extension 1 reaches to Kamailio. This is a simulation of push-based registration since an extension that receives the push will attempt to register when an incoming call is received.
When asterisk sends INVITE request to Kamailio, it immediately responded with 100 trying provisional response. This 100 response by Kamailio towards asterisk prevents asterisk from re-transmitting the INVITE.
Then Kamailio tried to send and retransmit the packet to extension 2, which does not have network access. This extension 2 was on port number 24071. Even after successful registration(in port 59995) of the extension 2, Kamailio continued to transmit the packets to the old port.
After that, we have configured Kamailio in a way that it won't send an immediate provisional reply(100 trying ) for INVITE request.
Here Kamailio is not immediately sending 100 trying message to Asterisk. This forces Asterisk to re-transmit. Asterisk was found to retransmit the same packets. However, even after the successful registration of extension 2, asterisk continued to send the old invite to Kamailio not the new one to the latest port.
This is the problem for me since push relies on the INVITE reaching the phone at the correct port number.
So, is there other good approaches to solve this issue?
One thing I would like to try is modifying the pending INVITE request towards old registered port with the new port details when new registration reaches to Kamailio. Can I get the ongoing requests from Kamailio?
Please suggest a viable solution.
Almost any kamailio config availible do similar thing.
You have save into location and consult it when do call.
However if you need really scalable platform you SHOULD NOT forward register requests to asterisk at all.
If kamailio send invite to wrong port, likly that mean you have TWO records in location.
Is it possible to transfer call to different host in asterisk?
Like I have three asterisk instances in line i.e A, B and C. The scenario is that the call will come from A to B and B will transfer the call to C and after successful transfer, B will not be facilitator and A will directly be communicating with C
Correct setup is have kamailio or opensips proxy infront of asterisk.
For asterisk ff you have on all instances in trunks settings
canreinvite=yes
directmedia=yes
and if you have SIP protocol, you can do Transfer call. If you do that before call setup will be full transfer,if after setup - only last option will work, so signaling will still go via this host, while media go directly.
Both options may not work if provider NOT support that.
pro-sip*CLI> core show application Transfer
-= Info about application 'Transfer' =-
[Synopsis]
Transfer caller to remote extension.
[Description]
Requests the remote caller be transferred to a given destination. If TECH
(SIP, IAX2, LOCAL etc) is used, only an incoming call with the same channel
technology will be transferred. Note that for SIP, if you transfer before
call is setup, a 302 redirect SIP message will be returned to the caller.
The result of the application will be reported in the ${TRANSFERSTATUS}
channel variable:
${TRANSFERSTATUS}:
SUCCESS: Transfer succeeded.
FAILURE: Transfer failed.
UNSUPPORTED: Transfer unsupported by channel driver.
[Syntax]
Transfer([Tech/]destination)
[Arguments]
Is it possible to expose a SOAP endpoint via BizTalk that calls another SOAP service without using orchestrations but just maps?
The current solution where orchestrations are being used is very slow (orchestration overhead is greater than 1,5 seconds) and performance gets even worse when it comes to high concurrency. I require a solution for low latency.
While not 100% sure for a SOAP endpoint, I have done this for WCF-BasicHttp, but cannot think of a reason why it would not be possible for SOAP. Various properties get promoted to the message context that would allow you to route a message to a send port, like the SOAP action, the receive port name, etc. Configuring a send port to subscribe to the relevant messages should be trivial. The mapping from the inbound-request to the outbound-request can happen on either the receive port or the send port.
In the case of using a solicit-response send port, the response message coming back would automatically be subscribed to by the originating receive port, assuming it is also two-way. Again, the mapping from the inbound-response to the outbound-response can happen on either the send port or the receive port.
I have an orchestration that takes a message. The target namespace is "http://microsoft.com/HealthCare/HL7/2X" and the root element is "ORU_R01_23_GLO_DEF"
In the orchestration, I map the message to an intermediate message type in a construct shape. The target namespace is "http://mycompany.com/myapplication" and the root element is "MyMessage". The "MyMessage" message is then further mapped and then sent to a web service using a logical send port in the orchestration. A WCF send port is then bound to the orchestration and everything works fine. Everything works as expected.
Without altering the orchestration, I want to create a send port that subscribes to the intermediate "MyMessage" message and writes it to a file. To do this, I have created a send port with a filter of BTS.MessageType = http://mycompany.com/myapplication#MyMessage.
Even though messages are flowing through the orchestration, my send port isn't picking up the message. Is this the incorrect filter to use?
Are you trying to subscribe to the 'MyMessage' message, or the same message that is sent to the logical Send Port bound to the physical WCF Send Port?
You have stated that:
The "MyMessage" message is then further mapped and then sent to a web service using a logical send port in the orchestration. A WCF send port is then bound to the orchestration and everything works fine.
Message not Published to MsgBox
From what you have described, I would suggest that you do not have a Send Shape/Logical Send Port combination in your orchestration for the 'MyMessage' message, which is why you can't manually subscribe to this message type in a Send Port filter. The fact that you have not mentioned a 'Failed Routing Report' message further suggests that this is the case - this message type is generated when no subscriotion can be found for a message that is to be published to the MsgBox.
Capture a Message's 'MessageType'
If however you need to capture a copy of the message your are sending over the WCF Send Port, you will need to determine its MessageType and use that in your second Send Port subscription that writes the message out to file.
If you are unsure as to what MessageType to use, there is a simple trick to determine this information:
Stop (not Unenlist) the WCF Send Port
Send a message through your orchestration as normal - the message will be marked as 'Suspended Resumable' in the BizTalk Admin Console on the WCF Send Port.
Open the message in the BizTalk Admin Console and view its 'Message Context'; in the Message Context you will see its 'MessageType' property which you can then use to understand which subscription filter to use.
Start the WCF Send Port to flush the message.
Alternatively, if you don't want to change your orchestration, you could try archiving your message as it passes through the Send Pipeline in the (original) WCF Send Port - either write your own archiving component or use an existing commercial component. By using an archiving component in this manner, you will save yourself the expense of an extra subscription and the associated Send Port maintenance.
Update:
It sounds very much like the OP is not sending the intermediate message to the Message Box from their Orchestration (see comments). Message subscription will only work when a message is published to the Message Box - in this case, the message in question ('Message B') is an intermediate message that only lives within the context & lifetime of the orchestration. The OP needs to Send the message to a Direct Bound port within the Orchestration to allow the message to be subscribed to via a Send Port.
Verify the pipelines of the Send Port. Should by XML, not Passthrougth.
I am trying to implement Reliable WCF Service with MSMQ based on this architecture (http://www.devx.com/enterprise/Article/39015)
A message may be lost if queue is not available (even cluster doesn't provide zero downtime)
Take a look at the simple order processing workflow
A user enters credit card details and makes a payment
Application receives a success result from payment gateway
Application send a message as “fire and forget”/”one way” call to a backend service by WCF MSMQ binding
The user will be redirected on the “success” page
Message is stored in a REMOTE transactional queue (windows cluster)
The backend service dequeue and process the message, completes complex order processing workflow and, as a result, sends an as email confirmation to the user
Everything looks fine as excepted.
What I cannot understand how can we guarantee that all “one way” calls will be delivered in the queue?
Duplex communication is not a case due to the user should be redirected at the result web page ASAP.
Imagine the case when a user received “success” page with language “… Your payment was made, order has been starting to process, and you will email notifications later…” but the message itself is lost.
How durability can be implemented for step 3?
One of the possible solutions that I can see is
3a. Create a database record with a transaction details marked as uncompleted, just to have any record about the transaction. This record may be used as a start point to process the lost message in case of the message will not be saved in the queue.
I read this post
The main thing to understand about transactional MSMQ is that there
are three distinct transactions involved in a transactional send to a
remote queue.
The sender writes the message to a local queue.
The queue manager on the senders machine transmits the message across the wire to the queue manager on the recipient machine
The receiver service processes the queue message and then removes the message from the queue.
But it doesn’t solve described issue - as I know WCF netMsmqBinding doesn’t use local queue to send messages to remote one.
But it doesn’t solve described issue - as I know WCF netMsmqBinding
doesn’t use local queue to send messages to remote one.
Actually this is not correct. MSMQ always sends to a remote queue via local queue, regardless of whether you are using WCF or not.
If you send a message to a remote queue then look in Message Queuing in Server Management you will see in Outbound queues that a queue has been created with the address of the remote queue. This is a temporary queue which is automatically created for you. If the remote queue was for some reason unavailable, the message would sit in the local queue until it became available, and then it would be transmitted.
So durability is provided because of the three-phase commit:
transactionally write message locally
transactionally transmit message
transactionally receive and process message
There are instances where you may drop messages, for example, if your message processing happens outside the scope of the dequeue transaction, and also instances where it is not possible to know if the processing was successful (eg back-end web service call times out), and of course you could have a badly formed message which will never succeed processing, but in all cases it should be possible to design for these.
If you're using public queues on a clustered environment then I think there may be more scope for failure as clustering msmq introduces complexity (I have not really used so I don't know) so try to avoid if possible.