Submitting messages to BizTalk using c# code

 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 »

BTS Data Services – More info

Hello

I hope you all read my post about BizTalk Data Services from here. The code associated with this post can be found at Tellago Devlabs

Here is a quick setup instructions and a link to a document with some use cases and screenshots of the results.

Setup instructions:

1. Create a new website in IIS:
   1. Give the web site a meaningful name.
   2. The code from the download page and all the samples will work out of the box if you make sure that the URL for the web site created above is http://localhost:8080/BTSDataServices/
   3. Make sure you can browse http://localhost:8080/BizTalkManagementService.svc/
2. Make sure that the account running the web site has access to “BizTalkMgmtDb” database.
3. Turn off “feed reading view” in IE:
   1. Internet options–> “Content” tab
   2. At the “Feeds and Web slices” click the “settings”
   3. Make sure that “Turn on feed reading view” is unchecked.

Sample usage scenarios and results:

This is the cool part, here you can find a document that has some usage scenarios with screenshots of the results.

Good Luck

Uri

Read Full Post »

Tellago’s DevLabs on CodePlex

Tellago, my current company, now has its own space on CodePlex.

our intent is to use this space to post open source projects that we are working on internally.

The first project is our “BizTalk Data Services” which I blogged about here.

check it out, it is very cool and very useful

Good Luck

Uri

Read Full Post »

BizTalk Data Services: Making BizTalk more RESTful with OData

By Jesus Rodriguez, Uri Katsir, Tellago, Inc 

The code referenced on this post is available at Tellago’s DevLabs CodePlex workspace: http://tellago.codeplex.com/releases/view/41246

Introduction

During the last few years, BizTalk Server has established itself as one of the dominant technologies in the integration ecosystem. As part of its current release, BizTalk Server includes a robust publish-subscribe engine along with technologies such as a Business Rules Engine and  Business Activity Monitoring that enable important capabilities for integration solutions. Together with its different subsystems, BizTalk Server includes a series of APIs that allow developers to dynamically leverage those capabilities in .NET applications. Currently, the use of these APIs is constrained to .NET environments and, for the most part, only experienced BizTalk developers are able to master those APIs. Having a more flexible and interoperable set of APIs will extend BizTalk capabilities to non .NET technologies such as J2EE or even other Microsoft technologies such as Windows PowerShell or dynamic languages such as IronPython or IronRuby. 

This document presents an overview to a RESTful API for BizTalk Server based on the Open Data (OData) Protocol. The fundamental objective of this API is to expose BizTalk resources via HTTP using the Atom Publishing Protocol (AtomPub) or the JavaScript Object Notation (JSON). Using these interfaces, developers should be able to interact with BizTalk Server with a simpler, more interoperable and lightweight mechanism. 

Why REST? Why OData?

As explained in the previous section, the purpose of the BizTalk Data Services API is to enable highly interoperable mechanisms to interact with BizTalk Server. We would like to leverage these APIs as a fundamental vehicle to leverage the capabilities of BizTalk Server into heterogeneous environments. In that sense, we’ve decided to rely on REST as the fundamental architecture style for our API. The use of REST enables us to expose BizTalk Server resources via a stateless, URI-based service enabled API that uses standard HTTP verbs as its fundamental interface. 

The use of REST does not impose any constraints on the mechanism used to represent BizTalk resources. We can expose BizTalk native elements such as receive or send ports using XML, XHTML, RSS, OData, etc. Specifically, OData provides an extensible resource representation mechanism based on AtomPub and JSON. OData was initially released as part of WCF Data Services and has gained a great adoption by various Microsoft technologies such as PowerPivot or SQL Server Reporting Services. 

BizTalk Data Services

The fundamental premise of the BizTalk Data Services API is to provide the foundations to interact with BizTalk Server using OData. In the initial release, we are targeting four fundamental BizTalk subsystems: 

• BizTalk Management Data Service:  This RESTful API exposes the functionalities available in the BizTalk Management Console via HTTP-based OData interfaces. Using this API developers can query/search artifacts such as Assemblies, Applications, Orchestrations, Ports, Schemas, Maps, etc.
• Business Rules Data Service: This RESTful API exposes BizTalk’s Business Rules as AtomPub/JSON resources. Using this API, developers can create, alter and execute BRE policies using simple HTTP requests.
• BAM Data Service:  This RESTful API exposes BAM and allows developers to interact with BizTalk Server BAM using AtomPub and JSON. Using this API developers can deploy, undeploy and query BAM activity models as well as creating, updating and querying BAM activities.
• BizTalk ESB Data Service: This RESTful API is the equivalent of the BizTalk management API for the new capabilities included in the BizTalk ESB toolkit. Using this API developers can interact with ESB artifacts such as Itineraries, Resolvers or Adapter Providers using AtomPub and JSON.

  

It’s important to notice that the current implementation is focused on the BizTalk Management Data Services API. 

BizTalk Management Data Services

The BizTalk Management Data Services API provides a lightweight interface for managing BizTalk artifacts such as Assemblies, Ports, Orchestrations, Schemas, Maps, etc an HTTP interface that leverages OData as the representation mechanism. The following examples detail some of the available features in the current version of the API. 

Sample Use Cases

This section includes various samples that illustrate how to interact with the BizTalk Data Services API. Specifically, the samples focus on the querying, navigation and filtering capabilities of the current version of the API. 

Basic Querying

The BizTalk Data Services API exposes various BizTalk Server artifacts as collections accessible via HTTP GETs. The following examples how to leverage the API to query BizTalk Server. 

Querying BizTalk applications: 

http://<WebApp>/BizTalkManagementService.svc/Applications 

Querying BizTalk assemblies: 

http://<Data Services Web App>/BizTalkManagementService.svc/Assemblies 

Querying BizTalk Hosts: 

http://<Data Services Web App>/BizTalkManagementService.svc/Hosts 

Querying BizTalk pipelines: 

http://<Data Services Web App>/BizTalkManagementService.svc/Pipelines 

Querying BizTalk receive handlers: 

http://<Data Services Web App>/BizTalkManagementService.svc/ReceiveHandlers 

Querying BizTalk schemas: 

http://<Data Services Web App>/BizTalkManagementService.svc/Schemas 

Querying BizTalk maps: 

http://<Data Services Web App>/BizTalkManagementService.svc/Transforms 

Querying BizTalk SendPorts: 

http://<Data Services Web App>/BizTalkManagementService.svc/SendPorts 

Querying BizTalk InProcess instances: 

http://<Data Services Web App>/BizTalkManagementService.svc/InProcessInstances 

Querying BizTalk InProcess messages: 

http://<Data Services Web App>/BizTalkManagementService.svc/InProcessMessages 

Querying BizTalk parties: 

http://<Data Services Web App>/BizTalkManagementService.svc/Parties 

Navigation

The BizTalk Data Services API leverages WCF Data Services to enable navigation across related different BizTalk Server objects. The following examples illustrate how to leverage this capability: 

Querying a specific send port:  

http://<Data Services Web App>/BizTalkManagementService.svc/SendPorts(‘SendPort1′) 

Querying all orchestrations in a specific assembly: 

http://<Data Services Web App>/BizTalkManagementService.svc/Assemblies(‘SampleBTSPrj’)/Orchestrations 

Retrieving the contents of an in-process message: 

http://<Data Services Web App>/BizTalkManagementService.svc/InProcessMessages(’09665a37-703e-4590-be25-d50f507995c2′)/Body/$value 

Retrieving the context of an in-process message:  

http://<Data Services Web App>/BizTalkManagementService.svc/InProcessMessages(’09665a37-703e-4590-be25-d50f507995c2′)/ContextProperties 

Retrieving a XML Schema definition:  

http://<Data Services Web App>/BizTalkManagementService.svc/Schemas(‘MSMQ.MSMQPropertySchema’)/XmlContent/$value 

Retrieving the generated XSLT of a BizTalk map: 

http://<Data Services Web App>/BizTalkManagementService.svc/Transforms(‘SampleBTSPrj.SampleMap1′)/XmlContent/$value 

Retrieving the source and target schemas of a BizTalk map: 

http://<Data Services Web App>/BizTalkManagementService.svc/Transforms(‘SampleBTSPrj.SampleMap1′)/SourceSchema 

http://<Data Services Web App>/BizTalkManagementService.svc/Transforms(‘SampleBTSPrj.SampleMap1′)/TargetSchema 

Filtering:

One of the most attractive features of the BizTalk Data Services API is the ability to filter a BizTalk Server collection using OData’s query expression. The following samples illustrates how to leverage this feature: 

Querying all stopped send ports: 

http://<Data Services Web App>/BizTalkManagementService.svc/SendPorts?$filter=Status%20eq%20′Stopped’ 

Querying all disabled receive locations for a specific receive port: 

http://<Data Services Web App>/BizTalkManagementService.svc/ReceivePorts(‘ReceivePort2′)/ReceiveLocations?$filter=Enable%20eq%20false 

Real world scenarios

After exploring the capabilities explained in the previous section, you can start thinking about real world scenarios that can benefit from the use of the BizTalk Data Services API. Generally, the use of a RESTful OData-based interface to communicate with BizTalk Server can drastically simplify some of the traditional tasks and challenges of BizTalk applications. The list below summarizes some of the most common scenarios that we have seen in our initial prototypes with customers: 

Lightweight management (PowerShell) 

Having a RESTful interface to interact with BizTalk Server facilitates the implementation of traditional BizTalk operational tasks with scripting technologies such as Windows PowerShell. Even though the latest release of BizTalk Server includes a PowerShell driver, this one is still dependant on the BizTalk client SDK. However, using a RESTful API will enable the interaction with multiple BizTalk Servers from PowerShell using only HTTP and OData. For instance, an administrator could quickly query the status of all the BizTalk Server Hosts by executing a simple HTTP GET from any Windows workstation without the need of installing any BizTalk libraries or tools. 

Lightweight notifications 

As explained in previous sections, the BizTalk Data Services uses AtomPub as its fundamental representation mechanism. This capability allows developers or IT administrators to subscribe to specific Atom feeds that describe relevant events. For instance, an IT administrator could configure an Atom reader to receive notifications when a specific receive location gets disabled. Similarly, an information worker can subscribe an Atom reader to feed that exposes messages routed through BizTalk Server that match a predefined criteria (ex: all purchase orders which amount exceeds $10000) 

Message tracking and querying 

One of the common challenges faced by customers in BizTalk applications is the ability of querying/searching specific tracked or in-process messages. Even though BizTalk Server enables sophisticated message tracking capabilities, it is not completely straightforward to programmatically leverage these from other applications. In general, only experienced BizTalk Server developers know how to effectively use the message tracking APIs and, currently, this is only possible from a .NET development environment. The BizTalk Data Services API exposes both types of messages as OData resources accessible via a simple HTTP GET. In that sense, developers can query specific messages by executing a HTTP GET against the BizTalk Data Services endpoint. This feature enables the integration of the BizTalk message tracking capabilities with other technologies such as reporting tools or even BizTalk Server BAM. 

Conclusion

The BizTalk Data Services  API is an experiment intended to bring the capabilities of RESTful/OData-based services to traditional BizTalk Server solutions. The API exposes BizTalk Server artifacts as OData resources available via HTTP. This initial release focuses on the BizTalk Server management capabilities and future releases are intended to target other technologies such as Business Rules, BAM or the BizTalk ESB toolkit.

Read Full Post »

How to debug a custom SharePoint web part

I recently had a task to write a custom SharePoint web part.

I was able to find couple of very good articles that detail the steps needed for this task.

couple of steps were missed from the articles that I found, specially around how to debug the custom web part within Visual studio.

here are the steps I had to do in order to be able to write and debug the custom web part: (mainly focusing on the debug portion)

1.   Install “Visual Studio 2008 extensions for Windows SharePoint” from here.
2. Create a blank SharePoint site using SharePoint Central Administration page.
3. Create a new web part project in Visual studio (once you complete step #1 above, this project type will appear in the list of available projects).
4. In the project properties –> Debug –> set the “start browser with URL” to the newly created site in step #2 above. (see image below)
5. Read this article and this one to learn more about how to write the code for the custom web part.
6. when you have some code ready to be debugged, all is left is to attach the visual studio process to the “w3wp” process from “tools –> Attach to Process…” and refresh the web part page.
7. if you need to do remote debugging read this article.

the key steps from the list above that will enable debugging of the custom web part are #2 and #4.

Good Luck

Uri

Read Full Post »

Modifying BTS Send Ports and Receive Locations using SQL and .Net Code

In my current project, the client has a need to be able to stop ans start all send ports and receive locations.

The requirement is to have the ability to perform the above in both bulk operation (starting/stopping all receive/send ports) and to have the ability to choose a specific receive location or send port.

The focus of this post is to outline a programmatic way achieving the above requirement using SQL and .Net code (no VB scripts, WMI events, PowerShell commands etc.)

  BizTalkMgmtDb database has 2 tables and 2 stored procs which are the focus of this post:

•   Receive Locations:
  • Table name: ”adm_ReceiveLocation” the table has a lot of useful information about the receive location that we can use in our application (like “ReceivePipelineId”, “ReceiveHandlerId” and many more).
  • The column we are interested for the purpose of this post is called “Disabled”.
    • [Disabled]= -1 –> Receive location is disabled
    • [Disabled]= 0 –> Receive location is enabled
  • built-in stored proc to manipulate the “Disabled” column is called “adm_ReceiveLocation_disable”
  • We can either use the above stored proc to enable/disable the receive locations or write our own custom code to interact with the table.
• Send Ports:
  • Table name: bts_sendport – as it is for the recieve locations, this table contains a lot of useful information we can use in our application.
  • The column we are interested in for the purpose of this post is called “nPortStatus”
    • nPortStatus = 1 –> send port unenlisted
    • nPortStatus = 2 –> send port stopped
    • nPortStatus = 3 –> send port started
  • as stated above, We can either use the above stored proc to stop/start the send ports or write our own custom code to interact with the table.

Good luck

Uri

Read Full Post »