Feeds:
Posts
Comments

Archive for the ‘ESB Toolkit 2.0’ Category

 Hello

Ever needed to send a message to BizTalk using c# native code?

if your answer is yes, you are reading the right post.

I will demonstrate 2 ways of submitting a message to BizTalk, one using a netPipe receive location and the other is using the ESB.OnRamp.Itinerary.WCF receive location. (Vishal Mody has a very good post on the netPipe bindings at his blog)

as the code below shows, it is all about the bindings…

The code

  • Add reference to the following assemblies:
    • System.ServiceModel
    • System.Runtime.Serialization
  • For both scenarios (netPipe and ESB on ramp) we create the interface:

//Using statements

using System.ServiceModel;
using System.ServiceModel.Channels;
using System.Xml;
using System.IO;

[ServiceContract()]
        private interface IBizTalkSubmission
        {
            [OperationContract(Action="*", ReplyAction="*")]
            void Submit(System.ServiceModel.Channels.Message msg);
        }

  • NetPipe receive location

public void SubmitDocument(string Xml)
        {

            //Create the Message
            System.ServiceModel.Channels.Message msg = System.ServiceModel.Channels.Message.CreateMessage(MessageVersion.Default, “*”, XmlTextReader.Create(new StringReader(Xml)));

            //Set required properties
            string uriLocationEsbOnRamp = “net.pipe://BizTalk/someName”;
            NetNamedPipeBinding b = new NetNamedPipeBinding();
            //Handle security if needed
            b.Security.Mode = NetNamedPipeSecurityMode.None;

            EndpointAddress epa = new EndpointAddress(uriLocationEsbOnRamp);
            IBizTalkSubmission proxy = ChannelFactory.CreateChannel(b, epa);
            //submit the message
            proxy.Submit(msg);

        }

  • ESB.OnRamp.Itinerary.WCF receive location

 public void SubmitDocumentUsingESB(string Xml)
        {
            Message msg = System.ServiceModel.Channels.Message.CreateMessage(MessageVersion.Default, “*”,
                                                                             XmlTextReader.Create(new StringReader(Xml)));

            string uriLocationEsbOnRamp = “http://localhost/ESB.ItineraryServices.WCF/ProcessItinerary.svc“;

            WSHttpBinding b = new WSHttpBinding();
            EndpointAddress epa = new EndpointAddress(uriLocationEsbOnRamp);
            IBizTalkSubmission proxy = ChannelFactory<IBizTalkSubmission>.CreateChannel(b, epa);

            proxy.Submit(msg);

        }

BTS admin console settings

 NetPipe receive location

make sure that the URI you have in the code ( string uriLocationEsbOnRamp = “net.pipe://BizTalk/someName” in our example) is the same in the URI section for  the transport properties.(see image below)

ESB.OnRamp.Itinerary.WCF receive location

 No need to modify any settings.

if you get an error regarding the body of the incoming message, look at the “Messages” tab for this receive location. in this example the “Body” element was in the “soap:Body” element so the settings is as shown below.

 

Read Full Post »

what happens if you have multiple applications that use the same dynamic send port configured using ESB.

Pros:

  • Single port to handle multiple end point addresses.
  • Single port to handle multiple transport types.

Cons:

  • No ability to easily set the host instance that the port will be excuted in.
  • No ability to stop the send port without impacting all end points.

in my current project we have many endpoints that use a single send port, the client has raised a concern that this will impact their ability to scale out and it will not enable them to stop sending messages to a specific end point without impacting the rest of their end points.

one possible workaround I found (with Bruno Spinelli’s help) was to create a static send port that has the same subscription filter as the dynamic send port. The static send port has to use the same pipeline that the dynamic send port is using (in my case, it is the “itinerarySendPassthrough” pipeline) . So I used the dynamic send port during design time in VS2008 but for production I created the static send port and removed the dynamic one.

This approach gives the client the flexibility he was looking for and also the ability to decide which endpoints will share the dynamic send port and which end points will have their own dedicated static send port.

Send me an email if you are interested in the source code for this post.

Good luck

Uri

Read Full Post »

We recently had an issue in my current project that involved making changes to existing and deployed schemas.

When we tried to deploy the schema we got an error message since we had maps depending on the old schema.

We are using ESB so we figured out (with Brad Tillman’s help) that there is no need to deploy maps into Biztalk. it is enough to add them to the GAC and the itineraries will use the maps from the GAC.

Now, since the map dll is in the GAC, Biztalk has no awareness of the maps so we can redeploy the schemas into Biztalk without having to uninstall the dependent artifacts.

This is useful when you have multiple endpoints dependant on canonical schemas and you want make changes to the canonical schemas.

Now, there is no need to remove all dependant endpoints to make the change. 

Good luck

Uri

Read Full Post »

Thank you to everyone who attended my presentation.

here is a link to the presentation and the demos.

I presented a high level overview of the ESB toolkit 2.0 and explained how the toolkit can change the way we develop and deliver software solutions with BizTalk.

I also presented 2 demos:

  1. In the first demo, I showed 2 WCF services (food and drinks order services) that expose 2 different WSDL’s. I demonstrated how we can communicate with both services using a single Itinerary, a single receive location and a single dynamic send port.
  2. In the second demo I showed how we can quickly use 2 deployed maps in order to accomodate a new business scenario.

 Thank you

Uri

Read Full Post »

Here are a few useful posts for working with the ESB toolkit 2.0

The posts are from Dwight Goins’s blog which is always a recommended reading:

Good Luck

Uri

Read Full Post »

I will be speaking  at the South Florida BizTalk User Group Meeting on Tuesday, November 10th.

My session is titled ”Agility with BizTalk and ESB Toolkit 2.0″ and touches upon the new ways that the ESB toolkit provides to enable agile software development with BizTalk 2009.

if you are interested please click here to attend.

Uri

Read Full Post »

When debugging/working with the ESB toolkit, one of the immediate things I noticed was the lack of ability to determine which itinerary step was executed. For example, if I had an itinerary with 5 steps in it, there was no way of telling which one was executed.

One possible workaround for this issues is by utilizing the trace output that Dwight had blogged about and the xml representation of the  itinerary stored in “EsbItineraryDb” DB:

  1. Open event log and look for entries similar to this: “Advanced to service with id d9f7515e151c4d53ab0dbf4065c71d5f”.
  2. Open “Itinerary” table in “EsbItineraryDb” DB and look at the value in “imITML” column associated with the  itinerary that was executed.
  3. The value in this column is an Xml representation of the Itinerary.
  4. Every step in the  itinerary is represented with “Service” element that has “id” and “businessName” (and other) attributes associated with it.
  5. The guid style number you see in event log represents the “id” value from this xml.
  6. you should be able to follow the itinerary flow and figure out which steps were executed by comparing the guid numbers in event log to the id values in the xml file.

the above might not be the cleanest/coolest way of achieving our goal but it works and it is better than guessing.

Good luck

Uri

Read Full Post »

Follow

Get every new post delivered to your Inbox.