I've got a weird issue which totally confused me. I have an orchestration that receives a file through Receive port and puts it to Send port with delivery notification. After that orchestration performs some other actions but my issue is with the part mentioned above. It works: I put a file to Receive location and it goes to appropriate destination folder.
But, if I assign to the Send port a filter that uses fields promoted in message and filter's expression is False it still works - I receive file in destination folder (however filter is False and Send port should not process this file). And once filter becomes True I receive...THREE equal files in destination folder!
Are there any logs that I can go through to try to figure out where these two extra files come from?
Even when you add a filter to a send port, if the Orchestration is bound to the send port, it will still send through that send port, regardless what other filters you put on it.
In the Admin Console you do a query for Subscriptions and find the send port, you will notice that it will have an OR condition with http://schemas.microsoft.com/BizTalk/2003/system-properties.SPTransportID == {GUID} and that is the filter that is used when a an Orchestration sends to a bound send port.
So check what the filter looks like for your send port. Also check to see if you have a send port group set up that includes that send port, as that would also cause a message to be sent to that send port if the filter on that matches.
What is probably happening is that the Orchestration is sending one, and the filter is matching the message received from the Receive Location. You will have to do some more digging to see why the third message.
Related
I have an orchestration that processes incoming messages that make a data call. If data is returned, a new message is created and sent back to the receive port via a "mover" BizTalk application. The original message is no longer needed, so I've been sending it to a discard folder. Is there a requirement in BizTalk that requires a message coming in to be sent out?
Each message that comes into BizTalk needs to be routed somewhere yes, otherwise it will suspend with a routing failure.
However as you are using an Orchestration, once it has consumed the message, and you don't need to send the original message anywhere from the Orchestration if you don't need it, when the Orchestration ends, that message will be gone
In message only scenarios, where you don't have an orchestration your options are
A file send port to a folder, where you have a script to clean them up
A null adapter on a send port, a null adapter is a custom adapter that takes the message from the message box and just discards it.
I've set-up two applications, one with FILE Receive Port and the other with a Send Port subscribing to that Receive Port with filter set as BTS.ReceivePortName == {ReceivePortNameHere}. I'm using BizTalk 2013 R2.
In the Receive Port, I'm using the pipeline 'BTAHL72XReceivePipeline'. And, in the Send Port, I'm using the pipeline 'BTAHL72XSendPipeline'.
When I drop a HL7 message into the Receive Port file location, it produces the error:
The Messaging engine failed to process a message submitted by
adapter:FILE Source URL:E:\InboundToBizTalk\*.hl7. 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.
However, I do have a subscription set. Why is this error occurring? Is there an issue with the pipeline component or the way I am using it?
On the Group Overview page search for "Subscriptions" and filter based on your Send port name.
Verify that you see an activation Subscription and confirm that the filter conditions on the subscription are correct.
The by far most likely causes:
A typo between the Receive Port Name and the value in the Filter.
The Send Port is not Enlisted or Started.
Do not use quotes in the filter property.
Turned out to be ACK which could not be routed therefore causing the whole flow to error. For an MLLP transport type, it is two way thus the ACK can be routed. For a FILE transport type, it is one way therefore ACK needs to be accounted for separately.
To get around this, another port was created which would subscribe to the ACK.
I have an orchestration which sends a message A to message box. Now I have 2 subscriber orchestrations which subscribe to the message based on a filter expressions.
Now when I send a message which is to be routed to Subscriber 1, everything works fine, but when a message for subscriber 2 is sent it is routed to destination folder but infinite copies are created in the destination folder. I have to stop the orchestration to stop the generation of duplicate copies of message.
What am I doing wrong?
Are you receiving the same message that you are sending? If so this will cause an infinite loop because your receive location will pick the message up when it is sent. You need to change the filter on the receive, set a flag in your message in the orchestration and then filter on that perhaps.
This is often a symptom of a feedback loop, i.e. where you have a situation like:
Implementing a receive port which listens to the location that a send port publishes messages.
Implementing a direct-bound orchestration with a send port configured to publish messages to the message box of the same schema that it receives (without any filtering)
This is especially common in direct bound (MessageBox) scenarios, as this doesn't have the additional filters which are applied with Specify Now / Later settings. The solution is usually to add an additional filter - either out of the box, such as BTS.ReceivePortName, or a custom context property) on subscribers, so that you can distinguish between messages which have already been processed.
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 have the same problem as described here:
I am using two orchestrations. First orchestration calls the second using direct binding through a two-way send port. Second orchestrion has a two-way receive port to send the result back to the first. Every thing is working as it should but I am getting the following exception.
A response message for two-way receive port "Unknown " 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.
And the suggested solution works as well (set the BTS.EpmRRCorrelationToken value to a random value, new GUID in my case, in the first orchestration before send to the direct binding port and then in the secod orchestration i copy the value from the inputMessage to the outputMessage, so the value remains the same. With this method BizTalk knows how to correlate the response back to the caller). But I can't understand why this works and if this a good way to solve the problem. The BTS.EpmRRCorrelationToken flow is the following:
When I don't change the BTS.EpmRRCorrelationToken property, it is the same in all messages which flow in the process, but why on Earth doesn't BizTalk change it instead if it can't correctly correlate the messages?
Changing this property is certanly OK in your case.
The problem is direct binding. When you use it, you actually going more "low-level" way and have to deal with how BTS publish-subscribe mechanism works.
Send-Receive port subscribes to receive a message with a specific BTS.EpmRRCorrelationToken. So when you post receive message again in the Message box (for second orch), receive port grabs it too and unsubscribes then. When you finally try to send a response - there is noone waiting for it. So you have to change that property until you sending response back to the port.