Say I were to create a promoted property on an HL7 v2 schema. I want to use this promoted property in order to correlate two messages in a parallel convoy. I did a dummy application without using HL7 schemas and all worked just as expected. To sum up what I did, see this tutorial.
It's actually quite simple, which is why I'm wondering there is a catch when it comes to the HL7 schemas.
I created the PropertySchema, Promoted the field I'm after in the HL7 body schema, everything compiled and deployed fine, I ran a query for the subscriptions on my receive ports and they look OK
http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {D2F99A76-E28A-4B3E-AC52-F4E2F92453C3}
And
http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == http://microsoft.com/HealthCare/HL7/2X#ORU_ALL_25_GLO_DEF
And
https://myNS.ECGCorrelationPropertySchema.CommonAccessionID Exists
However, I get a
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.
and looking in the Biztalk Group admin console, when I view the suspended messages, I don't see that the property has been promoted
Edit to add message context
Error Report Context
I have checked and double-checked, the schemas are there, there are duplicate schemas the Event log even shows A message was received of type http://microsoft.com/HealthCare/HL7/2X#ORU_ALL_25_GLO_DEF when I receive a message.
So now, I guess I have 2 questions:
If the promotions were happening successfully, would they show in the Message --> Context dialog (they did in my non-HL7 dummy app)
If they aren't supposed to show, is there a setting/property/anything somewhere I missed that is unique to using HL7v2 schemas?
Short answers:
1. Yes, provided this message came directly from the Receive Pipeline
2. No, once emitted from the disassembler, there is nothing special about an HL7 Message.
Make sure you're looking at the actual Suspended Message and not the Error Report. The best way to check this is to Stop, don't Unenlist, the Orchestration. The Message will then suspend Resumable.
Related
I am trying to identify the messages I am saving in a folder using MessageID property. However the MessageID values are different from the values I get when I use BTS.MessageID. Why?
In my orchestration I receive a message "myMsg" from a receive port (with receive pipeline: XML Receive). After that I check myMsg(BTS.MessageID) value with
System.Diagnostics.EventLog.WriteEntry("MessageID", System.String.Format("The Value = {0}", myMsg(BTS.MessageID)));
and I get for example this value: c9953bec-72a8-4274-9ea3-d7770c52d4ab
Then I send my message through a send port (with send pipeline: PassThruTransmit)
When the message is saved, the name is: {EE2AB9A1-FA3C-4737-BB02-6AC0C0EA5EBC}.xml
Why are they different? I thought they would be the same.
Each message is unique. Assume you have 2 send ports where that orchestration message would go to. Would you expect it to have the same message id as the one from the orchestration? I hope not, because you would have 2 instances of a message with the same message id. (Actually 3 because you should also count your orchestration message is).
I guess what you're looking for is the InterchangeID, this one stays the same.
What you are seeing is the expected behavior.
A Message is a single publication to the MessageBox so the Message published by the Receive Port is different from the Message published by the Orchestration, hence different MessageID values.
While you might 'know' it's the same message, to BizTalk, they're not.
I have built a flatfile schema with the flatfile schema wizard.
The schema is valid and I could successfully validate my test instance against the schema.(So the XML file was created correctly).
But when I put my test flat file into a receive location that uses a flatfile disassembler pipeline, nothing happens after the receive location has picked up the message (the logical receive port is bounded to an orchestration)
In the BizTalk Admin Console I only see in the tracked message events from the pipeline that the message has been received. But not sent.
Maybe some of you already had a similar issue and could help me here.
Tracked message events in the pipeline
So. The issue was a wrong declared header schema. I have rebuild it and after that it was working fine.
I have recognized the issue by removing the header schema from the pipeline properties and trigger a new process. At this time the message was created correctly (but with the header line due to a missing header schema that would prevent that line).
Thanks to all who helped here!
Within my BizTalk 2010 solution I have the following orchestration that’s is started by the receipt of a courier update message. It them makes a couple of call to AX's WCF AIF via two solicit-response ports, a Find request and an Update request.
For this application we are meeting audit requirements through use of the tracking database to store the message body. We are able to link to this from references provided in BAM when we use the TPE. The result for the customer is nice, they get a web portal from which they can view BAM data of message timings etc. but they can also click a link to pull up a copy of the message payloads from the tracking db. Although this works well and makes use of out-of-box functionality for payload storage it has led to relatively complex jobs for the archiving of the tracking db (but that's another story!).
My problem relates to continuation. I have created the following Tracking Profile:
I have associated the first of the orchestration's two solicit response ports with the continuation RcvToOdx based on the interchange Id and this works, I get the following single record written to the Completed activity table:
So, in this case we can assume that an entry was first written on receipt in the inbound message, with the TimeReceivedIntoBts column populated by the physical file receive port. The FindRequestToAx column was then populated by the physical WCF send port. Because this was bound to the RcvToOdx continuation Id and used the same interchange Id and the previously mentioned file receive message, the update was made to the same activity. Notification of the resulting response was also updated to the same activity record - into the FindResponseFromAx column.
My problem is that I would also like BAM to record a timestamp for the subsequent UpdateRequestToAx. Because this request will have the same interchange Id as the previous messages I would expect to be able to solve this problem by simply binding the AxUpdate send port (both send and receive parts of it) to the same continuation id, as seen in the following screen grab:
I also map the UpdateRequestToAx milestone to the physical Ax_TrackAndTraceUpdate_SendPort (Send) and the OrchestrationCompleted milestone to Ax_TrackAndTraceUpdate_SendPort (Receive)
Unfortunately, when I try this I get the following result:
Two problems can be seen from the above db screen grab:
1. Date for the update send port was inserted into a new activity record
2. The record was never completed
I was surprised by this because I'd thought since they update port was enlisted to use the same continuation, and the single InterchangeId was being used by all ports for the continuation Id then all the data milestones would be applied to a single activity.
In looking for a solution to this problem I came across the following post on Stack Overflow suggesting that the continuation must be closed from the BAM API: BAM Continuation issue with TPE. So, I tried this by calling the following method from an expression shape in my orchestration:
public static void EndBAMContinuation(string continuationId)
{
OrchestrationEventStream.EndActivity(CARRIER_ORDER_ACTIVITY_NAME, continuationId);
}
I can be sure the method was called ok because I wrapped the call with a log entry from the CAT framework which I could see in debug view:
I checked the RcvToOdx{867… continuation Id against the non-closed activity and confirmed they matched:
This would suggest that perhaps the request to end the continuation is being processed before the milestone of the received message from the UpdateAx call?
When I query the Relationsips tables I get the following results:
Could anyone please advise why the UpdateToAx activity is not being completed?
I realise that I may be able to solve the problem using only the BAM API but I really want to exhaust any possibility of the TPE being fit for purpose first since the TPE is widely used in other BizTalk solutions of the organisation.
To solve this problem I created a 2nd continuation in the TPE.
"RcvToOdx" continuation for the Find and "OdxToUpdate" continuation for the update - source is InterchangeId on the initial receive port - UPS_TrackAndTrace (same as for other "RcvToOdx" continuation), dest Id is the InterchangeId mapped to update send port.
I'll try provide as much information as possible:
No error message.
The instance stays in the "ready service instances".
The receive location has the same parameters (except URI, the three polling queries, user account/pw and receive pipeline) as another receive location that points to another database/table which works.
The pipeline is waiting for the correct schema.
The port surface and receive location are both waiting for the correct schema.
In my test example, there are only 10 lines being returned.
The message, which contains those 10 lines, validates against the schema.
I tried to let the instance alone to no avail - 30+ minutes - and no change in its condition.
I had also tried suspending and then resuming it which then places the instance in the "dehydrated orchestrations" list. Again, with no error message.
I'm able to get the message by looking at the body of the message that's in the "ready to run" service. (This is the message that validates versus the schema I use in Visual Studio.)
How might something like this arise?
Stupid question, but I have to ask... Is the corresponding host instance running?
I'm relatively new to Biztalk and I'm having a bit of hassle with this:
I have built a simple orchestration, hooked it up correctly to a receive port, I'm using the correct schema and map and the orchestration seems to be subscribing ok.
However, when the file I want to process gets picked up at the port I'm getting the 'could not be routed because no subscribers were found' error.
I ran a HAT query and can see the orch has an active subsription to the correct thing, is there anything else I can check on this?
Is your port hooked directly to the orchestration or is the orchestration picking the message up from the message box? Has the orchestration receive been set to Activate?
What does your subscription filter look like for the orchestration?
As a futher test:
a) create a sendport (FILE)
b) add a filter to it; BTS.ReceivePortName =
c) grab the resulting file - it should be the XML thats produced by your Custom PL
d) Use this file with a receive location using an XML Receive PL and see how your orchestration reacts to
This will at least rule out a Pipeline issue...
HTH
Check your pipeline is XMLReceive. This will promote the MessageType property and hopefully your orchestration will subscribe successfully.
Find the failed message in HAT and look at the body of the message. Copy it out and then run validate it against the schema of the message you are expecting. If it doesn't validate then you have set your flat file disassembler up incorrectly.