I have an issue with send port:
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.
But this send port sent messages successfully but then I still see this message in Suspended.
Any ideas how is it possible?
It isn't saying that there isn't a subscription on the send port, it is saying your message doesn't match any subscription on anything.
You need to check the context properties on the suspended message and compare it to the subscription on the send port you expect the message to go to. You will find that they do not match.
Related
I would like to queue requests made by mobile application that uses API to send some data to the server.
The scenario for now is like this:
Mobile app sends a request with some data
I need to get the data, validate it (a few DB queries) and save to a few tables in DB.
I need to return OK response to mobile app or bad request with erros list in case the validation has failed.
Now if I have 1 000 requests like this in 3 seconds my server will collapse.
I would like to use RabbitMQ to queue those requests. But what should I do with a response? I cannot send OK after RabbitMQ has received the message cause I don't know if the validation will pass. So mobile app will wait until RabbitMQ message will be properly consumed?
This could be a solution to your problem:
The client sends a request
The server queues the request and generate a unique identifier that belongs to the queued request, and then sends a response containing the generated identifier with 202 (Accepted) status code that means the request has been queued or submitted on the server but there is no response yet.
The client subscribes to the generated identifier on a message broker
After a queued request finished on the server it will publish a response to the message broker based on the generated identifier for a request
The client will receive published response on the subscribing identifier
Tips:
I use EMQTT for the message broker. Another option would be Rabbitmq MQTT plugin
I have a mirth channel that listens to a source and then deploys the inbound communications to several channels. One of these channels sends the HL7 to an application I am developing, and I do not know where to send my ack message. Should I send it to the inbound port of the original message, or does MIRTH have a specific process for sending acknowledgements?
Acknowledgements in Mirth are handled in destination's Response Transformer. To get there, go to the Destinations tab, select your destination if there are more than one, under Channel Tasks menu on the left side select Edit Response. The msg variable there is your response message. To generate an acknowledgement use Postprocessor script or place your acknowledgement into responseMap directly and configure the Response setting of the Source connector.
In one of our solutions (pure messaging, no orchestrations), we receive a message on a request response receive location, using the MLLP adaptor and HL7v2x pipelines. The receive pipeline generates the response message and publishes it, which due to promoted properties gets routed through the send pipeline of the request/response receive port, back to the client.
We then have a two way send port that subscribes to the received message, uses a map to translate the message and send to a request response WCF receive port that is also on the same BizTalk machine. It sounds odd but we have clients that send their data via web services, and some that send via HL7v2 MLLP so that's why we're doing it this way.
The WCF request response receive port also generates a response by publishing a message and promoting the EpmRRCorrelationToken, CorrelationToken, ReqRespTransmitPipelineID, RouteDirectToTP, IsRequestResponse and ReceivePipelineResponseConfig properties, which causes the response to get routed through the send pipeline as a SOAP response.
We subscribe to the messages received on the WCF request response port, and drop them to a file.
Technically it works. The client using MLLP gets an acknowledgement response. The client using WCF SOAP web services get a SOAP response. The file system contains all messages that were sent.
So if I think about the messages published I imagine there is the HL7v2 message received over MLLP (A), and the HL7v2 response (B). Then the translated messages received by the WCF receive port (C), and it's response (D). Plus the WCF response that was received by the WCF send port (E), as shown in the attached .
The problem is that we're getting suspended messages in BizTalk such as "A response message for two-way receive port "xxx" is being suspended as the messaging engine could not correlate the response to an existing request message. This usually happens when the host process has been recycled." In this case, the service is the MLLP receive port, and there are 3 suspended messages - the HL7v2 ACK (B), and 2 copies of the response message for the WCF service (D) and (E) I suspect.
We're also seeing errors "The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended."
With MLLP adapter Its possible that the Receive MLLP is timing out. There are few things you can look at:
The Persistent Connection Property should be set to True with Receive Timeout Set to 0
Since you are calling a WCF service for published HL7 message which come via MLLP, I am wondering if you are dealing with WCF service response. If not then it will cause these error messages. You need to subscribe to the service response or use a one way send port.
Relook at your design and need of calling a local WCF service when a message is received via MLLP to send the message to a FILE location. You can do this directly skipping all the WCF route in between.
I am working on a sip client - asterisk server. I am using tcp connections.
The client side is Zoiper as for a first test.
Registration and outbound calls do work as expected, but after 3-4 minutes from registration process or an outgoing call, when testing incoming calls I do get this message on the server:
tcptls.c:446 ast_tcptls_client_start: Unable to connect SIP socket to ip:port: Connection timed out
The invite message (incoming call) never gets on the client (Zoiper softphone).
Why is this error showing up?
The reason why this appears from my assumption is because of the fact that neither the client or the server are sending keep alive messages, so after a tcp socket timeout the client which is behind a nat will not be reachable from the server side anymore.
This error come because your NAT (or 3g if you use 3g) drop connection. As result there are no way use same connection anymore.
Correct behavour of you app - send SIP OPTIONS message, if timeout - do registration again.
And yes, you need send keepalives(recomended method - OPTIONS message) or setup keepalive on asterisk side and setup in your side correct answer.
I have a BizTalk 2010 project containing an orchestration that needs to make an HTTP Post and then examine the Status Code and Body of the Response to determine the next course of action.
I can configure the orchestration and port to make the HTTP Post, but I am unable to receive a response.
Should I be using a send / receive port or correlation?
What schema should I be using for the response (I believe the response is the standard http response: http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6).
If you are looking for a kind of notification ( not in content of the message) that the message has been successfully transmitted, you can set the logical send port property in the orchestration as follows:
"Delivery Notification" = Transmitted
And delivery failures can be handled using the Microsoft.XLANGs.BaseTypes.DeliveryFailureException
The Http Status Code should be available on the Response message as a Context Property, which you can access in an Expression shape.
statusCode = ResponseMessage(HTTP.ResponseStatusCode);
Your ResponseMessage should be of type System.Xml.XmlDocument, but as it won't be a real Xml Document, make sure the Request/Response port is configured to use the PassThruReceive pipeline on the Response side.