Saving original HL7 message with MLLP.

[bouchaet]

I like to share my spike with HL7 in case some of you would be
interested to share some thoughts.

The curious issue :
Where is the original HL7 message? The ___messages are not tracked as
an original flat-file HL7___ when using HAT with the MLLP adapter.

And the real deal:

1 Context
An integration solution with BizTalk Server 2006/2006 R2 is deployed
in production. A new version of the solution was completed and ready
to be deployed. However it is not possible to fully assert its quality
without running messages in production. I know, please do not "5whys"
me on this (http://en.wikipedia.org/wiki/5_Whys). For now, it must be
seen as a constraint. The pre-production environment cannot have
external systems that would reliably reproduce the production
environment. Production messages are highly valuable and must not be
ruined by the system. A backup plan is mandatory.

The nature of the communication, HL7 exchange, yield to another
functional constraint: the receiving sequence of the messages must be
maintain for the resubmission.

If a system back out must be held, no production messages should be
lost. Moreover, the messages must be re-injected once the back out is
completed. BizTalk Server can route ingoing messages to a dedicated
database of its tracking system.

2 Problem
How this system performs in a critical scenario and how could it be
used to resubmit messages?

3 Forces
# The archiving mechanism does not involve a new development;
# The receiving sequence is known and it can be reproduced during the
resubmission;
# The archiving mechanism is not permanent and can be de-activated;
# The original message is not modified and can be inspected as-is by
an administrator;

4 Current Finding

4.1 The Test set-up
To perform a test, an existing in-production application was used in
DEV environment. This application already has a suite of performance
tests written with loadgen [http://www.microsoft.com/downloads/
details.aspx?FamilyID=c8af583f-7044-48db-
b7b9-969072df1689&displaylang=en]. However, the tests does not clearly
identify the sequence of messages that is sent to the BizTalk engine
since it is using a file adapter on its receiving side. A new test
suite was created which runs from a batch file and works with a MLLP
receive port, an adapter that supports ordered delivery. The batch
file launches the mllpsend tool shipped with the HL7 accelerator.

4.2 Exploration One: Using HAT UI
* Tracking is enabled from the receive port;
* The messages can be saved from the UI with a right-click. However,
there is two major problem:
** the ___original messages is not saved___ in the Tracking database.
Only the XML version is available;
** the UI does not allow a multi-selection. In a scenario where there
is many messages (> 50), this is simply not workable on an
administration perspective;
* A tool on Codeplex, a plugin for HAT [http://
btsviewerhatplugin.codeplex.com] solves the previous multi-selection
problem. However, after few tests, the plugin does not work as
documented on the site. The messages are simply not shown in the UI
for no clear reason;

4.3 Exploration Two: Using Custom UI
* Tracking is enabled from the receive port;
* The UI client was download from Thiago Almeida blog [http://
connectedthoughts.wordpress.com/2008/04/02/3-ways-of-programatically-
extracting-a-message-body-from-the-biztalk-tracking-database/]. See an
image here [http://connectedthoughts.files.wordpress.com/2008/04/
trackedmessagewindowsform.jpg];
* However, to see the message, the user must know the message guid;
* No multi-selection available from the UI but the article presents
how messages can be retrieved from custom code;
** The tracking system offers theses views :
*** [BizTalkDTADb].[dbo].[btsv_Tracking_Parts] : this view holds the
data for the message (the body) in its imgPart column;
*** [BizTalkDTADb].[dbo].[btav_MessagesFacts] : this view contains all
the information related to the message like the adapter type [Event/
Adapter], the port name [Event/Port], the timestamp [Event/Timestamp]
(which could be used for the sequencing), [Event/Direction]
** The tracking system offers stored procedures for tracked messages:
*** [BizTalkDTADb].[dbo].[GetTrackedMessage]
*** [BizTalkDTADb].[dbo].[GetTrackedMessageFragments]
*** [BizTalkDTADb].[dbo].[GetTrackedMessageParts]


5 Early Conclusions
5.1 Where is the original HL7 message?
The big issue is that ___messages are not tracked as an original flat-
file HL7___. This issue may discard the BTS tracking system as a
potential backbone for an archiving-and-resubmission feature.

5.2 Multiple is not :
Out-of-the-box, HAT UI cannot provide a solution for message. The
messages are indeed archived in its database and are not so hard to
reach individually. However, it is not a workable solution for
multiple instances.

5.3 Resubmission needs thoughts :
Both HAT UI and Codeplex Tracked Message UI do nothing for
resubmission. In the best case, messages can be saved to a folder.
Nevertheless, these files are useless since messages retrieved from
the FILE adapter cannot support ordered delivery. However, the
tracking views in the BizTalkDTADb database can be queried to retrieve
an ordered sequence of messages for a given adapter or port name.
Theses messages could then be sent to an ordered aware adapter.

Any comments?

Thanks,

etienne
bouchaet.blogspot.com

[j***@gmail.com]

Post by bouchaet
I like to share my spike with HL7 in case some of you would be
interested to share some thoughts.
Where is the original HL7 message? The ___messages are not tracked as
an original flat-file HL7___ when using HAT with the MLLP adapter.
1 Context
An integration solution with BizTalk Server 2006/2006 R2 is deployed
in production. A new version of the solution was completed and ready
to be deployed. However it is not possible to fully assert its quality
without running messages in production. I know, please do not "5whys"
me on this (http://en.wikipedia.org/wiki/5_Whys). For now, it must be
seen as a constraint. The pre-production environment cannot have
external systems that would reliably reproduce the production
environment. Production messages are highly valuable and must not be
ruined by the system. A backup plan is mandatory.
The nature of the communication, HL7 exchange, yield to another
functional constraint: the receiving sequence of the messages must be
maintain for the resubmission.
If a system back out must be held, no production messages should be
lost. Moreover, the messages must be re-injected once the back out is
completed. BizTalk Server can route ingoing messages to a dedicated
database of its tracking system.
2 Problem
How this system performs in a critical scenario and how could it be
used to resubmit messages?
3 Forces
# The archiving mechanism does not involve a new development;
# The receiving sequence is known and it can be reproduced during the
resubmission;
# The archiving mechanism is not permanent and can be de-activated;
# The original message is not modified and can be inspected as-is by
an administrator;
4 Current Finding
4.1  The Test set-up
To perform a test, an existing in-production application was used in
DEV environment. This application already has a suite of performance
tests written with loadgen [http://www.microsoft.com/downloads/
details.aspx?FamilyID=c8af583f-7044-48db-
b7b9-969072df1689&displaylang=en]. However, the tests does not clearly
identify the sequence of messages that is sent to the BizTalk engine
since it is using a file adapter on its receiving side. A new test
suite was created which runs from a batch file and works with a MLLP
receive port, an adapter that supports ordered delivery. The batch
file launches the mllpsend tool shipped with the HL7 accelerator.
4.2 Exploration One: Using HAT UI
* Tracking is enabled from the receive port;
* The messages can be saved from the UI with a right-click. However,
** the ___original messages is not saved___ in the Tracking database.
Only the XML version is available;
** the UI does not allow a multi-selection. In a scenario where there
is many messages (> 50), this is simply not workable on an
administration perspective;
* A tool on Codeplex, a plugin for HAT [http://
btsviewerhatplugin.codeplex.com] solves the previous multi-selection
problem. However, after few tests, the plugin does not work as
documented on the site. The messages are simply not shown in the UI
for no clear reason;
4.3 Exploration Two: Using Custom UI
* Tracking is enabled from the receive port;
* The UI client was download from Thiago Almeida blog [http://
connectedthoughts.wordpress.com/2008/04/02/3-ways-of-programatically-
extracting-a-message-body-from-the-biztalk-tracking-database/]. See an
image here [http://connectedthoughts.files.wordpress.com/2008/04/
trackedmessagewindowsform.jpg];
* However, to see the message, the user must know the message guid;
* No multi-selection available from the UI but the article presents
how messages can be retrieved from custom code;
*** [BizTalkDTADb].[dbo].[btsv_Tracking_Parts] : this view holds the
data for the message (the body) in its imgPart column;
*** [BizTalkDTADb].[dbo].[btav_MessagesFacts] : this view contains all
the information related to the message like the adapter type [Event/
Adapter], the port name [Event/Port], the timestamp [Event/Timestamp]
(which could be used for the sequencing), [Event/Direction]
*** [BizTalkDTADb].[dbo].[GetTrackedMessage]
*** [BizTalkDTADb].[dbo].[GetTrackedMessageFragments]
*** [BizTalkDTADb].[dbo].[GetTrackedMessageParts]
5 Early Conclusions
5.1 Where is the original HL7 message?
The big issue is that ___messages are not tracked as an original flat-
file HL7___. This issue may discard the BTS tracking system as a
potential backbone for an archiving-and-resubmission feature.
Out-of-the-box, HAT UI cannot provide a solution for message. The
messages are indeed archived in its database and are not so hard to
reach individually. However, it is not a workable solution for
multiple instances.
Both HAT UI and Codeplex Tracked Message UI do nothing for
resubmission. In the best case, messages can be saved to a folder.
Nevertheless, these files are useless since messages retrieved from
the FILE adapter cannot support ordered delivery. However, the
tracking views in the BizTalkDTADb database can be queried to retrieve
an ordered sequence of messages for a given adapter or port name.
Theses messages could then be sent to an ordered aware adapter.
Any comments?
Thanks,
etienne
bouchaet.blogspot.com

Etienne,

A couple thoughts:

1. When message body tracking is enabled on the receive port _before_
port processing the contents of the HL7 message (in its original flat
file, delimited state) should be available in HAT. When you pull up a
tracked message in HAT it brings back the context of the message (XML)
and the actual body of the original message. It may not be ideal if
you want to save a collection of messages to disk and immediately
resubmit them, but you can at least get the original message when you
need it.

2. I've been faced with the issue of bulk resubmission of HL7
messages in the past and, like you, I've found that HAT cannot
accomplish this task. HAT works fine when attempting to retrieve a
handful of messages but its usefulness in the resubmission process
ends there. If ordered delivery is a major concern (and it almost
always is with HL7), you may want to consider building a custom
process to extract messages from the tracking database and resubmit
them. I've done this in the past and it has worked great.
Hint: Take a look at the
Microsoft.BizTalk.Operations.BizTalkOperations object for the
extraction of messages from the tracking database.

Jonathan Brown

[bouchaet]

Post by j***@gmail.com

Post by bouchaet
I like to share my spike with HL7 in case some of you would be
interested to share some thoughts.
Where is the original HL7 message? The ___messages are not tracked as
an original flat-file HL7___ when using HAT with the MLLP adapter.
1 Context
An integration solution with BizTalk Server 2006/2006 R2 is deployed
in production. A new version of the solution was completed and ready
to be deployed. However it is not possible to fully assert its quality
without running messages in production. I know, please do not "5whys"
me on this (http://en.wikipedia.org/wiki/5_Whys). For now, it must be
seen as a constraint. The pre-production environment cannot have
external systems that would reliably reproduce the production
environment. Production messages are highly valuable and must not be
ruined by the system. A backup plan is mandatory.
The nature of the communication, HL7 exchange, yield to another
functional constraint: the receiving sequence of the messages must be
maintain for the resubmission.
If a system back out must be held, no production messages should be
lost. Moreover, the messages must be re-injected once the back out is
completed. BizTalk Server can route ingoing messages to a dedicated
database of its tracking system.
2 Problem
How this system performs in a critical scenario and how could it be
used to resubmit messages?
3 Forces
# The archiving mechanism does not involve a new development;
# The receiving sequence is known and it can be reproduced during the
resubmission;
# The archiving mechanism is not permanent and can be de-activated;
# The original message is not modified and can be inspected as-is by
an administrator;
4 Current Finding
4.1  The Test set-up
To perform a test, an existing in-production application was used in
DEV environment. This application already has a suite of performance
tests written with loadgen [http://www.microsoft.com/downloads/
details.aspx?FamilyID=c8af583f-7044-48db-
b7b9-969072df1689&displaylang=en]. However, the tests does not clearly
identify the sequence of messages that is sent to the BizTalk engine
since it is using a file adapter on its receiving side. A new test
suite was created which runs from a batch file and works with a MLLP
receive port, an adapter that supports ordered delivery. The batch
file launches the mllpsend tool shipped with the HL7 accelerator.
4.2 Exploration One: Using HAT UI
* Tracking is enabled from the receive port;
* The messages can be saved from the UI with a right-click. However,
** the ___original messages is not saved___ in the Tracking database.
Only the XML version is available;
** the UI does not allow a multi-selection. In a scenario where there
is many messages (> 50), this is simply not workable on an
administration perspective;
* A tool on Codeplex, a plugin for HAT [http://
btsviewerhatplugin.codeplex.com] solves the previous multi-selection
problem. However, after few tests, the plugin does not work as
documented on the site. The messages are simply not shown in the UI
for no clear reason;
4.3 Exploration Two: Using Custom UI
* Tracking is enabled from the receive port;
* The UI client was download from Thiago Almeida blog [http://
connectedthoughts.wordpress.com/2008/04/02/3-ways-of-programatically-
extracting-a-message-body-from-the-biztalk-tracking-database/]. See an
image here [http://connectedthoughts.files.wordpress.com/2008/04/
trackedmessagewindowsform.jpg];
* However, to see the message, the user must know the message guid;
* No multi-selection available from the UI but the article presents
how messages can be retrieved from custom code;
*** [BizTalkDTADb].[dbo].[btsv_Tracking_Parts] : this view holds the
data for the message (the body) in its imgPart column;
*** [BizTalkDTADb].[dbo].[btav_MessagesFacts] : this view contains all
the information related to the message like the adapter type [Event/
Adapter], the port name [Event/Port], the timestamp [Event/Timestamp]
(which could be used for the sequencing), [Event/Direction]
*** [BizTalkDTADb].[dbo].[GetTrackedMessage]
*** [BizTalkDTADb].[dbo].[GetTrackedMessageFragments]
*** [BizTalkDTADb].[dbo].[GetTrackedMessageParts]
5 Early Conclusions
5.1 Where is the original HL7 message?
The big issue is that ___messages are not tracked as an original flat-
file HL7___. This issue may discard the BTS tracking system as a
potential backbone for an archiving-and-resubmission feature.
Out-of-the-box, HAT UI cannot provide a solution for message. The
messages are indeed archived in its database and are not so hard to
reach individually. However, it is not a workable solution for
multiple instances.
Both HAT UI and Codeplex Tracked Message UI do nothing for
resubmission. In the best case, messages can be saved to a folder.
Nevertheless, these files are useless since messages retrieved from
the FILE adapter cannot support ordered delivery. However, the
tracking views in the BizTalkDTADb database can be queried to retrieve
an ordered sequence of messages for a given adapter or port name.
Theses messages could then be sent to an ordered aware adapter.
Any comments?
Thanks,
etienne
bouchaet.blogspot.com

Etienne,
1.  When message body tracking is enabled on the receive port _before_
port processing the contents of the HL7 message (in its original flat
file, delimited state) should be available in HAT.  When you pull up a
tracked message in HAT it brings back the context of the message (XML)
and the actual body of the original message.  It may not be ideal if
you want to save a collection of messages to disk and immediately
resubmit them, but you can at least get the original message when you
need it.
2.  I've been faced with the issue of bulk resubmission of HL7
messages in the past and, like you, I've found that HAT cannot
accomplish this task.  HAT works fine when attempting to retrieve a
handful of messages but its usefulness in the resubmission process
ends there.  If ordered delivery is a major concern (and it almost
always is with HL7), you may want to consider building a custom
process to extract messages from the tracking database and resubmit
them.  I've done this in the past and it has worked great.
Hint: Take a look at the
Microsoft.BizTalk.Operations.BizTalkOperations object for the
extraction of messages from the tracking database.
Jonathan Brown

Hi Jonathan,

Thanks for sharing.

(1) A colleague and I have tried to obtain the original HL7 messages
from the receive port by enabling the tracking _before_ port
processing. We have ran multiple tests and with two different
environments. We always ended up with empty message bodies. Only
message contexts are available. Is it a configuration issue? Is there
an option to enable somewhere with the MLLP adapter?

(2) I will have a look at methods available from BizTalkOperations
class. Mmmh. just did. All GetTrackedMessage overloads require a GUID
as parameter. Isn't easier to use the DB views and stored procedures
to filter out undesired messages?
*** [BizTalkDTADb].[dbo].[btsv_Tracking_Parts] : this view holds the

Post by j***@gmail.com

Post by bouchaet
data for the message (the body) in its imgPart column;
*** [BizTalkDTADb].[dbo].[btav_MessagesFacts] : this view contains all
the information related to the message like the adapter type [Event/
Adapter], the port name [Event/Port], the timestamp [Event/Timestamp]
(which could be used for the sequencing), [Event/Direction] *** [BizTalkDTADb].[dbo].[GetTrackedMessage]

*** [BizTalkDTADb].[dbo].[GetTrackedMessageFragments]
*** [BizTalkDTADb].[dbo].[GetTrackedMessageParts]

But as you say, the best (read quickest) option is to build a custom
resubmission system over the tracking database. But the original HL7
messages tracking must work in first place!

etienne

[Tom Canter - Neudesic]

Etienne,
In an earlier post you noted that you were using HL7 v1.3 with BizTalk
Server 2006.

What I do know is:
1) There have been historical problems with tracking the Inbound
before-pipeline message body, that was fixed in HL7 for 2004, so...
2) Inbound message body tracking works, proven over and over
3) Sometimes, if you don't have sufficient capacity, the inbound
message body will not get moved to the tracking database due to SQL
load
4) If this is a potential production system, I would be sure to engage
Product Support to resolve the issue
5) You have properly explored all the known solution approaches, and
you are on the right track
6) The lack of inbound message body tracking pre-pipeline is either
due to an unknown bug, or issues with the tracking engine in BTS due
to system configuration

So, start simple
1) Does inbound pre-pipeline message tracking work for non HL7
Messages?
2) Confirm that all SQL Jobs are running succesfully, especially the
Backup BizTalk Server job that keeps the system healthy, this will
reduce the load on the system and possibly resolve the system load
3) Look for errors in the system, does the system have any SQL or
event log errors that you need to track down, don't disregard
anything, whatever is not working could be related to unexpected
problems
4) Report back results! I look forward to your info!

Thanks,
Tom

[bouchaet]

Post by j***@gmail.com
Etienne,
In an earlier post you noted that you were using HL7 v1.3 with BizTalk
Server 2006.
1) There have been historical problems with tracking the Inbound
before-pipeline message body, that was fixed in HL7 for 2004, so...
2) Inbound message body tracking works, proven over and over
3) Sometimes, if you don't have sufficient capacity, the inbound
message body will not get moved to the tracking database due to SQL
load
4) If this is a potential production system, I would be sure to engage
Product Support to resolve the issue
5) You have properly explored all the known solution approaches, and
you are on the right track
6) The lack of inbound message body tracking pre-pipeline is either
due to an unknown bug, or issues with the tracking engine in BTS due
to system configuration
So, start simple
1) Does inbound pre-pipeline message tracking work for non HL7
Messages?
2) Confirm that all SQL Jobs are running succesfully, especially the
Backup BizTalk Server job that keeps the system healthy, this will
reduce the load on the system and possibly resolve the system load
3) Look for errors in the system, does the system have any SQL or
event log errors that you need to track down, don't disregard
anything, whatever is not working could be related to unexpected
problems
4) Report back results! I look forward to your info!
Thanks,
Tom

Hi Tom,

Thanks for your comments and suggestions. My colleague and I did not
have time to dig into the problem a little more but we will before the
end of the week. Nevertheless, based on our notes, here is some
answers to your questions:

* Our test environment was using W2k3SP2, BizTalk Server 2006 R2 and
BTAHL72.0. Both in french.
* Tracking is successful with the MLLP Two-way Receive port for :
** message context _before_ inbound port processing;
** message body and context _after_ inbound port processing (HL7 in
xml format);
** message body and context before and after outbound port
processing;
* The tracking works for message body and context before port
processing when using a FILE receive adapter;
* All sql jobs were configured but we have to check the history for
errors, if any;
* I do not recall viewing any errors in the event viewer but as you
say it is worth to reassess everything;

I will try to give you more details by the end of the week,

Thanks,

etienne

[bouchaet]

Post by bouchaet

Post by j***@gmail.com
Etienne,
In an earlier post you noted that you were using HL7 v1.3 with BizTalk
Server 2006.
1) There have been historical problems with tracking the Inbound
before-pipeline message body, that was fixed in HL7 for 2004, so...
2) Inbound message body tracking works, proven over and over
3) Sometimes, if you don't have sufficient capacity, the inbound
message body will not get moved to the tracking database due to SQL
load
4) If this is a potential production system, I would be sure to engage
Product Support to resolve the issue
5) You have properly explored all the known solution approaches, and
you are on the right track
6) The lack of inbound message body tracking pre-pipeline is either
due to an unknown bug, or issues with the tracking engine in BTS due
to system configuration
So, start simple
1) Does inbound pre-pipeline message tracking work for non HL7
Messages?
2) Confirm that all SQL Jobs are running succesfully, especially the
Backup BizTalk Server job that keeps the system healthy, this will
reduce the load on the system and possibly resolve the system load
3) Look for errors in the system, does the system have any SQL or
event log errors that you need to track down, don't disregard
anything, whatever is not working could be related to unexpected
problems
4) Report back results! I look forward to your info!
Thanks,
Tom

Hi Tom,
Thanks for your comments and suggestions. My colleague and I did not
have time to dig into the problem a little more but we will before the
end of the week. Nevertheless, based on our notes, here is some
* Our test environment was using W2k3SP2, BizTalk Server 2006 R2 and
BTAHL72.0. Both in french.
  ** message context _before_ inbound port processing;
  ** message body and context _after_ inbound port processing (HL7 in
xml format);
  ** message body and context before and after outbound port
processing;
* The tracking works for message body and context before port
processing when using a FILE receive adapter;
* All sql jobs were configured but we have to check the history for
errors, if any;
* I do not recall viewing any errors in the event viewer but as you
say it is worth to reassess everything;
I will try to give you more details by the end of the week,
Thanks,
etienne

Tom,

We just spent the last few hours testing MLLP tracking capabilities.

Our environment is VPC with
* W2k3SP2 EN
* BizTalk Server 2006 R2 EN
* BTAHL7 2.0 EN

We ran nearly 50 different attempts. We use different message types,
encoding, BTApipeline success status, accentuate character or not.
Here is what we obtained:

Attempt # Time Message type Encoding Passed parsing Accentuate
Résultat Remark
MLLP Adapter Two-Way
1 ??? string ??? no no ok "ceci est un test"
2 ??? string ??? no no ok "ceci est un test"
3 ??? string ??? no yes failed "ceci est un test àéîçï"
4 ??? hl7 1kB ??? no no ok with LPAT
5 ??? hl7 1kB ??? no yes ok last OBX with "annulé" and LPAT
6 ??? string ??? no yes ok "ceci est un test àéîçï"
7 ??? hl7 55kB ??? yes yes failed
8 13:52 string ??? no no ok "ceci est un test"
9 13:53 string ??? no yes failed "ceci est un test àéîçï"
10 13:57 hl7 1kB ??? no no failed with no parsing error LPAT --

Post by bouchaet
LHEAD

11 13:58 hl7 1kB ??? yes no failed with parsing error LHEAD -->
LPAT. Contradict attemp # 4
12 14:12 hl7 1kB ??? no no failed Same message as attempt # 11.
No new post. Saved from HAT after 14 minutes
13 14:19 hl7 1kB UTF8 no no failed 934 bytes. With "LPAT"
14 14:23 hl7 1kB UTF8 no yes failed 935 bytes. With "LPAT"
15 14:28 hl7 1kB ANSI no no failed 931 bytes. With "LPAT"
16 14:29 string ANSI no no ok "ceci est un test". 16bytes
17 14:30 string UTF8 no no invalid "ceci est un test". 19bytes.
There is 4 saved messages (2 context and 2 bodies). However, tracking
is enable for request message body only.
18 14:31 string UTF8 no no invalid "ceci est un test". 19bytes.
There is 4 saved messages.
19 14:35 string UTF8 no no ok "ceci est un test". 19bytes.
20 14:39 hl7 1kB UTF8 no no failed
21 14:40 hl7 1kB UTF8 yes no failed
DTA Purge And Archive is disabled
23 ??? hl7 1kB UTF8 no no failed
24 ??? hl7 55kB ANSI yes yes failed
25 ??? hl7 1kB UTF1 6 LE no no failed
26 ??? hl7 1kB ANSI no no failed
27 ??? string UTF8 no no ok "ceci est un test"
28 15:24 string UTF8 no yes ok "ceci est un test àéÎçï"
29 15:25 hl7 1kB UTF8 no yes failed
30 15:25 hl7 1KB UTF8 yes no failed
Restart Host instances
31 15:27 hl7 1kB UTF8 yes yes ok
32 15:28 hl7 1kB UTF8 yes yes failed
33 15:29 hl7 1kB UTF8 yes yes failed
Restart Host instances
34 15:31 hl7 1kB UTF8 yes yes ok
35 15:31 hl7 1kB UTF8 yes yes failed
36 15:33 hl7 55kB ANSI yes yes failed
Restart Host instances
37 15:34 hl7 55kB ANSI yes yes failed
Restart Host instances
38 15:36 hl7 55kB UTF8 yes yes failed
39 15:38 hl7 1kB UTF8 yes yes failed
Restart Host instances
40 15:41 hl7 1kB ANSI no no ok with LPAT
41 15:42 hl7 1kB ANSI no yes failed last OBX with "annulé" and
LPAT
42 15:43 string UTF8 no no ok "ceci est un test"
43 15:44 string UTF8 no yes invalid "ceci est un test àéÎçï".
Il a retourné 4 lignes
MLLP Adapter One-Way, Restart Host Instances
44 15:55 hl7 1kB ANSI no no ok with LPAT
45 15:57 hl7 1kB ANSI no no failed with LPAT
46 15:58 string UTF8 no no invalid "ceci est un test". There is
4 saved messages.
47 16:02 string UTF8 no no ok "ceci est un test"

So, we were unable to find a pattern. Based on this attempts, the
tracking seems to have a very random behavior for HL7 messages. In
fact, most of the time, it simply does not work. We still cannot
understand how this is supposed to work.

étienne

[Tom Canter - Neudesic]

Etienne,
There can be no doubt that you have some kind of problem.
Whether is is something particular to your environment or you have
uncovered a bug in the HL7 Accelerator remains to be seen.
I strongly urge you to contact your local microsoft team and also open
a support request with microsoft.

You may note that the only supported encodings are ASCII/ANSI, UTF8
and Western European, the test with UTF16LE is not supported.
http://msdn.microsoft.com/en-us/library/bb945593.aspx

Thanks, good testing!
Tom

[j***@gmail.com]

Etienne,

We began experiencing the exact same tracking issue recently. The
fact that it occurs intermittently caused us to miss it during our
initial testing phase but we definitely noticed it once we started
running performance tests. We've opened a ticket with Microsoft and
have been told that they believe it is a defect in the accelerator.
The issue has been handed over to their development team.

I'll let you know if I hear anything else.

-John

[bouchaet]

Jonathan,

Finally, we are glad to read that we are not alone living with this
issue. We have also opened a case with Microsoft two weeks ago.
Apparently, the product group is working on a fix.

I will give you an update when we will receive new information.

Thanks for sharing,

étienne