Monthly Archives: February 2012

BizTalk Patterns part 2–Sync Async

Posted on by

Developing a BizTalk Server solution can be challenging, and especially complex for those who are unfamiliar with it. Developing with BizTalk Server, like any software development effort is like playing chess. There are some great opening moves in chess, and there are some great patterns out there to start a solution. Besides being an outstanding communications tool, design patterns help make the design process faster. This allows solution providers to take the time to concentrate on the business implementation. More importantly, patterns help formalize the design to make it reusable. Reusability not only applies to the components themselves, but also to the stages the design must go through to morph itself into the final solution. The ability to apply a patterned repeatable solution is worth the little time spent learning formal patterns, or to even formalize your own. This entry looks at how architectural design considerations associated to BizTalk Server regarding messaging and orchestration can be applied using patterns, across all industries. The aim is to provide a technical deep-dive using BizTalk Server anchored examples to demonstrate best practices and patterns regarding parallel processing, and correlation.

Read more at http://blogs.msdn.com/b/appfabriccat/archive/2010/10/16/biztalk-patterns-part-2-sync-async.aspx
Authored by Thiago Almeida

Deployed zillion times to fix this error.

Posted on by

Error Description :-

The adapter failed to transmit message going to send port "WcfSendPort_MyWebService_MyWebServiceSoap" with URL http://localhost/MyWebService/MyWebService.asmx. It will be retransmitted after the retry interval specified for this Send Port. Details:"System.ServiceModel.ProtocolException: The remote server returned an unexpected response: (400) Bad Request. —> System.Net.WebException: The remote server returned an error: (400) Bad Request.
   at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelAsyncRequest.CompleteGetResponse(IAsyncResult result)
   — End of inner exception stack trace —

Server stack trace:
   at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
   at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
   at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
   at System.ServiceModel.Channels.ServiceChannel.EndRequest(IAsyncResult result)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at System.ServiceModel.Channels.IRequestChannel.EndRequest(IAsyncResult result)
   at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)".

 

My Remarks:-

I feel little nauseating after deploying close to zillion timesSmile with tongue out (Hypothetically) in attempt to fix this error since this morning. All I am doing is call a web service using a WCF-BasicHTTP adapter in my BizTalk Project.

The webmethod takes the string as the input parameter and return string..Plain simple right? but the catch is I am send a huge XML serialized to string to the Webmethod.

At first, I thought it to be a problem with the size of the data, But no..that was not the case. I realised that after increasing the maxReceivedRequestSize on the send port and similarly on the web service by modifying web.config with the below

<system.web>     <httpRuntime maxRequestLength="2097150" executionTimeout="3000"/>   </system.web>

Second, I had to identify the problem using brute force / Trail and error basis, As the great BizTalk would not allow you to debug the Message Assignment shape. After trying and retrying couple of times, I realized that interfacing is good – I am able to send huge XML message from Orchestration to Web Service without issue.

Third, It was the problem with how I constructed the SOAP request in the message assignment shape (because I did not want to use Transform shape), I was assigning a part of my input multipart message direclly to my SOAP Request XML, So this was messing up the entire intention of the code and made be run this errand to fix it.

Finally, Voilà – the issue is fixed and I can sign off happily and enjoy my weekend.

Adopted Healthcare Integration Transmission.

Posted on by

HL7 / EDI file using TCP/ IP over VPN : –

  1. Considering the challenges and effort needed to make this happen, I am surprised to see this is still the technology we use to get integrated with most of the healthcare entities such as clinics, hospitals..etc.
  2. In reality, Once the Small Sized Clinics choose the EMR, they tend to stay with it for years and most of them may not opt for the premium support offered by these EMR vendors. Hence the software in the clinic remains old-school and it get hard to get integrated with such EMR using other communication medium.
  3. Main pain point getting integrated using this method, – Network teams from both the ends needs to get involved, exchange the Firewall settings, IP Address, Port numbers and make a Hole in both Firewall so the packets can traverse through it.
  4. Chances of VPN connectivity going down can be seen often  – whenever either entity do any modifications in the Firewall rules / policies.
  5. Here the message would be transmitted in the Transport layer of OSI, hence the overhead of the layers above transport is eliminated.
  6. We can use “ telnet 10.XX.XX.XX <port>” in the command prompt to check if the VPN connectivity is up.
  7. I would recommend this only to entities such as big hospitals / insurance companies which has multiple locations across the country and want to
      • Save over the network bandwidth during exchange of healthcare data (HL7 or HIPAA ) files.
      • Reduce transmission latency.
      • Afford a good network team.

sFTP : –

…To be contd.