Why BizTalk

Some people still ask me why BizTalk, they say that they can spin up a windows service and do most of the stuff !!!, i basically tell them following OOB features apart from the main ones, and they say………………………………… oh

  1. Transactional pipelines
  2. Recoverable pipelines
  3. Pipelines that call the BAM interceptor API
  4. BizTalk Server adapter support
  5. Batching
  6. Retries
  7. Correlation set initialization
  8. Declarative configuration
  9. Secondary transports
  10. Tracking
  11. Declarative use of BAM

NetHttpBinding, Web Sockets and what’s new in WCF 4.5 in a nutshell

1) What are Web Sockets

Its a new protocol implemented over tcp/ip to support duplex communications over the web.

2) How is it diffrent from HTTP

a) Http is stateless WebSockets are statefull, meaning you don’t have to identify your self always for every request.

b)With Http your server cannot send data to a client, without the client asking for it (you can achieve this with Long Polling and Polling only  which are not out of the box and are not pure duplex), with Web Sockets this is out of the box and is pure duplex communication and also you can reuse the same connection.

3) Http-Keep Alive

Yes you can keep an HTTP connection open, but this is still not sufficient enough because your HTTP server cannot send data on its own with out the client asking for it.

4) What is NetHttpBinding

Its a Microsoft’s implementation of Web Sockets and its supported in Framework 4.5

Large files routing approach in BizTalk

Problem: Large files routing in BizTalk

 Approach:

1) Create a WCF LOB Adapter/extend the SDK File adapter to implement file system watcher to monitor for files in a folder.

2) Once the file is created in the folder, create a new message containing the full path of the file and drop into message box via a custom receive pipeline component which promotes the absolute path of the file (c:\In\LargeFileName.xyz)

3) Create a custom send pipeline component which creates a new message and we associate the messageBody  property to the file (available in the context) using file stream (c:\In\LargeFileName.xyz)

4) Create a send port with the message type filter subscribing to the message created in step 2 and use the send pipeline component created in step 3.

This will also support retries and we have completely  eliminated MsgBox which would be a bottleneck

Bulk insert using WCF SQL Adapter

We had a scenario where we had to do a bulk insert of about 200 msgs into sql, after a lot of branistomring and googling we came up with the following solution

– Create a new table type
CREATE TYPE [dbo].[BulkInsertDBType] AS TABLE(
      [ID] [nvarchar](50) NULL,
      [Creation_Date_Time] [nvarchar](50) NULL
)

– Create a stored proc with  MERGE  

 

Create PROC [dbo].[sp_BulkInsertInsert]
 @List  BulkInsertDBType READONLY
  
AS
      SET NOCOUNT ON
      SET XACT_ABORT ON 
     
      BEGIN TRAN
      MERGE BulkInsertDBTable AS [Target]
USING @List   AS [Source]
ON [Target].[ID] = [Source].[ID]
WHEN NOT MATCHED THEN
    INSERT ( [ID], [Creation_Date_Time] )
    VALUES ( [Source].[ID], [Source].[Creation_Date_Time]);
COMMIT

Conclusion: the new WCF SQL Adapter supports table data type which helps for inserting bulk data!

Configure BizTalk for WCF tracing

Add the following to the biztalk config for tracing all the WCF calls and messages

<system.diagnostics>
    <sources>
      <source name=”System.ServiceModel.MessageLogging”>
        <listeners>
          <add name=”messages”
          type=”System.Diagnostics.XmlWriterTraceListener”
          initializeData=”c:\wcfTrace.e2e” />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>

Why is method overloading not supported in WCF services???

In order to answer this question first we need to understand the following WSDL styles:

1) RPC : Operation oriented say ex: InsertStudent,  <soap:body> element should contain the name of the method that is being invoked </soap:body

2) Document: is data oriented <soap:body> does not care what is being passed in the soap body </soap:body, this style came into the picture because of the limitations of RPC style where schema validation was difficult, included the type information and don not conform to WSI and etc..

Extensions for the above

3)Document/Literal: Microsoft proposed this standard where the soap body element will contain the web method name.

Now imagine a wsdl having the same name in WCF, we can’t because by default all the WCF services conform to the document literal standard where the soap body should include the method name , so this why we cannot have method overloading (same method name but different parameters) in WCF.