by community-syndication | Apr 21, 2007 | BizTalk Community Blogs via Syndication
I am working on a large project where we need to query Commerce Server to create data feeds to send to such sites as MSN Shopping, Yahoo Shopping, PriceGrabber, etc. When we create these data feeds we need to query for every item in the catalog.
There are a couple of blogs out there with examples of querying for a specific item but in this case I needed to get every single item. One of the things that was not clear to me was if I was supposed to use the field name defined in Commerce Server or if I was supposed to use the column name that I found in the database.
Well, it turned out that I was supposed to use the column name of the database that I wanted to search on.
We had an Inventory catalog and I found that all of the current data had a the value of 1 in the status column. So, in my Orchestration I created a message based on the InventoryQuery schema (msgInventoryQuery )and created the message in a ConstructMessage shape using the following xml in the MessageAssignment shape.
msgInvXmlDoc=new System.Xml.XmlDocument();
msgInvXmlDoc.LoadXml(“<CommerceServerInventoryQuery InventoryCatalog=’Default’ SearchClause=’Status=\”1\”‘/>”);
msgInventoryQuery = msgInvXmlDoc;
For the catalog query I created a message using the CatalogQuery schema and created the following message
msgCatXmlDoc=new System.Xml.XmlDocument();
msgCatXmlDoc.LoadXml(“<CommerceServerCatalogQuery ProductCatalog=” SearchClause=’DefinitionName =\”ProductGroup\” or DefinitionName =\”ProductItem\”‘/>”);
msgCatalogQuery = msgCatXmlDoc;
In this orchestration I had 4 queries that I was doing against Commerce Server and needed to receive them in whatever order they came back. I utilized a parallel shape with the receive shape connected to a request / response port. Then I used a Solicit-Response send port for the physical send port utilizing the Catalog and Inventory Commerce Server adapters.
After deployment and binding I am now able to query Commerce Server and receive the entire contents of the catalog.
by community-syndication | Apr 19, 2007 | BizTalk Community Blogs via Syndication
When deploying a BizTalk 2006 solution from Visual Studios, you may have encountered errors similar to this one:
Error 6 Failed to update binding information.
Could not enlist orchestration ‘DataStream.SOL.ScaterServiceRequests,DataStream.SOL.Demo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=806c67aab899168c’.
Could not enlist orchestration ‘DataStream.SOL.ScaterServiceRequests’. All orchestration ports must be bound and the host must be set….(read more)
by community-syndication | Apr 19, 2007 | BizTalk Community Blogs via Syndication
All I can say is I have not blogged for 2 months! Far out. No excuses. For those of you who have commented / left messages, thanks! So there is LOTS to talk about. Stay tuned….. 😉
by community-syndication | Apr 19, 2007 | BizTalk Community Blogs via Syndication
Companies use BizTalk Server in a variety of configurations. Let’s see this scenario:
Scenario: Company-X is a medium sized company they got variety of small BizTalk applications like “Order Processing”, “Payroll Processing”, “Payment Processing” etc. But they only have one BizTalk infrastructure (they got replica setting for testing and production) with 2 BizTalk application servers (BizTalk group) connected to 2 SQL servers clustered. All their BizTalk applications are deployed in this BizTalk group. All the applications are configured to run within the default In-Process and Isolated host and one instance per host is created on both the application servers.
The main issues with the above scenario are:
- Every time a new application is deployed or existing application is upgraded the host instances needs to be restarted (to refresh cached components). Stopping or restarting the host instance is going to affect each and every deployed application. At the minimum none of the applications are going to process any messages during the upgrade process.
- Security can be compromised, because there is no security boundary between applications.
- If one application causes problem to the host instance it’s going to affect the overall system.
The solution to the above mentioned problems is to create separate logical hosts for each application and then creating corresponding host instances. Logical hosts can be created for BizTalk application using variety of tools that comes out of the box like BizTalk administration console, WMI, etc, but we’ll face the following issues
- A thorough understanding of the host and host instances concept is required for the person who is performing the task.
- Creating logical host and configuring the BizTalk artifacts manually (handlers, receive locations, send ports and orchestrations) are error prone.
- Managing multiple logical hosts and their corresponding configuration will become more difficult over time.
ApplicationHostCreator is designed to create and manage logical hosts for BizTalk applications seamlessly to support situations as described in the above scenario.
Read more about how to use the tool and download version 1.0 of the tool at http://www.biztalk247.com
LINK: http://www.biztalk247.com/v1/articles/appHostCreator.aspx
Nandri!
Saravana
by community-syndication | Apr 19, 2007 | BizTalk Community Blogs via Syndication
Dynamic send ports are used in situations, where you don’t know in advance the type of transport adapter to use to send messages to your trading partner. May be based on certain content in your message you need to make that decision at runtime to pick up the transport adapter. The below figure shows the configuration for a Dynamic One-Way Send port, you can see you only specify the Name and Pipeline details (you can specify some of the other properties like maps, filters, etc).
Example Scenario: Say you are receiving an order message as shown below, which contains the “From” and “To” information in the header.
<Order>
<Header>
<From>me</From>
<To>Contoso</To>
</Header>
<Body>………</Body>
</Order>
Based on the “To” (trading partner name) you need to pick up the appropriate transport (ex: Contoso = FTP, Northwind=HTTP).
Dynamic Send port works very well with Orchestration, all you need to do is specify the following line inside your expression shape
Port_1(Microsoft.XLANGs.BaseTypes.Address) = “http://www.tradingpartner.com/receive.ashx“
That’s all it requires to route the message to dynamic send port. BizTalk resolves the correct transport address from the URI you specified.
(I put the following screen shot, so you know what I’m talking about)
Behind the Scene:
When you create a Dynamic Send Port from BizTalk management console and start it, in the background BizTalk creates subscriptions for all the adapters installed in your server. A query for subscription shows the following result.
If you look at the expression used inside the subscription you’ll see it’s looking for 3 properties “OutboundTransportType” (HTTP,FILE,FTP etc), “SPID” (Send Port Id) and existence of “OutboundTransportLocation”. The below figure shows the expression used for SendPort4: HTTP
When the orchestration submits the message to the MessageBox it promotes these three properties in the message context, which then gets picked up by the corresponding Dynamic Send Port.
How to use Dynamic Send Port without Orchestration?
If you want to use Dynamic Send Port in a content based routing scenario (aka Messaging-Only scenario) one option is to promote the 3 properties
- OutboundTransportType
- SPID
- OutboundTransportLocation
somewhere in your receive pipeline using custom pipeline component and submit it to the message box, which will then be picked up by the corresponding Dynamic Send Port. The only problem with this approach is SPID (Send Port id) is a system generated value and it might differ from environment to environment.
So, what’s the best solution?
All you need to do is define a new FILTER in your Dynamic send port, example BTS.ReceivePortName == <<your receive port name>>. That’s all it requires. Now if you look at the expression for SendPort4: HTTP you can see it accepts 2 different conditions one with SPID OR the other other one with ReceivePortName. So, all you need to do now is promote the following properties somewhere in your receive pipeline and submit the message to the MessageBox.
- ReceivePortName
- OutboundTransportType
- OutboundTransportLocation
Instead of ReceivePortName you can use whatever promoted property you have in your system. Now, you know for sure those values are not going to change like SPID.
Nandri!
Saravana
by community-syndication | Apr 18, 2007 | BizTalk Community Blogs via Syndication
- DHTML Site – Free 16×16 Icons
by community-syndication | Apr 18, 2007 | BizTalk Community Blogs via Syndication
One of the major challenges in Real World SOA enterprise applications is the lack of semantic information associated with Service Contracts. For a while now the W3C folks have been working in different efforts for relating semantic web Standards (RDF,…(read more)
by community-syndication | Apr 18, 2007 | BizTalk Community Blogs via Syndication
After my last post on this topic Alan Smith left a comment on my blog.
His comment was a good point and is worthy republishing here, to round out the topic.
Here it is verbatim:
“I’d agree with you there that quite a few .net ppl will try to solve problems with C#, rather than learning the correct way to solve things in BizTalk. I spent my first few weeks thinking “I can do this in 2 hours in C#, why does it take me 2 days in BIzTalk?”. As you get your head aroud how BizTalk works, you do things in BizTalk in 2 hours that would take 2 days (or 2 weeks) to do in C#.
But there’s also a catch 22 here, if I was hiring a BIzTak guy, i’d pick someone who was a good .net (or java) developer. Even though you don’t ‘usually’ write much code, there are situations when you need to, and you need to have good programming skills to do so. Custom pipeline components, custom functoids, and C# utilities to call from orchestrations are usually required (ok, maybe not functoids) on most BizTalk projects, and the code for these component needs to be solid.
Along with the dangers of having .net ppl solving everyting with C#, you also have the danger of ppl who are scared of programming jumping into BizTalk development because thay think it’s easy, and think they can build apps by drawing things.”
It never occurred to me that a non developer would look at BizTalk as a way to dev work with out code. Thats never gonna work. BizTalk is well and truly a developer technology.

by community-syndication | Apr 18, 2007 | BizTalk Community Blogs via Syndication
A few people have asked for the BizTalk 2004 version of this BizTalk SqlBulkInsert 2006 Adapter
Follow the below instructions to install on BizTalk 2004:
1) Download the zip file at the end of this blog entry.
2) When unzipping, unzip it a different folder such as: C:\temp
3) Copy the unzipped contents -> C:\Temp\BTSBulkLoad\SqlBulkInsertAdapter directory
to the C:\BTSBulkLoad\ directory that was created by the BizTalk 2006 zip file that you can find here:
(Look at the bottom of the above referenced blog entry for the download and Readme instructions).
Just replace the VS2005 C:\BTSBulkLoad\SqlBulkInsertAdapter folder contents with the VS2003 SqlBulkInsertAdapter directory contents.
4) Follow the below installation instructions for the BizTalk 2006 adapter to install the BTS 2004 adapter
Remember that this is just a prototype, so you will have to fix the code to get it to work properly. Peter (see comments from this blog entry) has stated that he has a BizTalk 2004 version of the adapter working.
Download the BizTalk 2004 adapter (Zip file) here
by community-syndication | Apr 18, 2007 | BizTalk Community Blogs via Syndication
There’s a new BizTalk newsletter/website on the web: BizTalkHotRod (found
through Richard
Seroter), created by some Microsoft Technology Specialist and other members of
the community. The first issue can be found here.
I find the layout and overall design of the website and newsletter to be pretty awful
(my opinion), but suffering through that is well worth it to get to the actual
content. Lots of great stuff on the first issue guys, so keep’em coming!