BizTalk Error Messages in Detail
long time ago I asked if MS could document the error messages that come out of the various parts of BizTalk.
My wishes were granted today, and I have a detailed list of error code/message for all of these below:
Common BizTalk Deployment Issues & Solutions
Deploying BizTalk application is a challenging task, which requires some special knowledge beyond desktop or web application deployment. In this blog, I will discuss some very common deployment issues and their solutions.
I usually choose manually deploy BizTalk application to other computers due to the time constraint to write automation script. A typical deployment cycle consists […]
New blog aggregated feed: BizTalkBlogs.com
There’s a cool new resource out there that acts as a central registry for bloggers that are blogging about BizTalk, WCF, WF, SOA, ESB (which pretty much covers everything I think about all day long :)) and related technologies and topics. If you look at the names of the bloggers, you’ll see the top names in this space, so this will surely become a great resource for Oslo content too as we enter that exciting era.
You can now go to a single point and get an aggregated view across a wide breadth of blogs, without needing to maintain the bloglist yourself. Pretty cool, and it has an RSS feed you can subscribe to. If you’re doing anything in this space, then this should be a “must see” resource for you. I know I’ll be checking the feed regularly, and thanks Microsoft for making this happen!
Check it out at http://www.BizTalkBlogs.com
Technorati Tags: BizTalk,ESB,SOA
BizTalk Deployment Poster Now Available
If you’re setting up a BizTalk environment, or considering growing your existing configuration, take a peek at the just-released BizTalk Scale-Out Options poster from Microsoft (hat tip: Eric).
Not sure I’d revisit this poster that often (compared to the BizTalk Capabilities poster or the Runtime Architecture poster which are both hanging in my office), but, it’s […]
BizTalk Server R2 Scale-Out Configuration Poster
Are you interested in a concise summary of some of the scale-out options for BizTalk Server R2? How about if the summary was a poster you could print out, tack to a wall, and cover with Post-It’s? If so, look no further than the BizTalk Server 2006 R2…(read more)
We Are Microsoft – We Are Sogeti
The day has arrived, and it is time for the We Are Microsoft, Charity Challenge Weekend.
My team, Team Sogeti, has been given the chance to help City
House with an internal Windows SharePoint Services (WSS) portal. We’ve recruited
some of the SharePoint brains within Sogeti, and I will be playing second fiddle to
them and taking up the branding/skinning of the site.
Our team, as it stands currently, consists of:
-
Bryan
-
Jason
-
Gavin
-
Deepak
-
Tim (Me)
We’ll have some part time support from Sogeti’s uber-brain of SharePoint Tuc, and
the occasional drop in from time to time this weekend from others. Of course
worthy of note also is the support of my wife, Kate, who has agreed to “Team Mom”
this wayward band, making sure they can stay focused by helping keep them in cokes/red
bull/monster/etc.
See everyone there later today, especially Improving and Telligent!
Tim Rayburn is a consultant for Sogeti in the Dallas/Fort
Worth market.
RESTful services description languages
Steve Vinoski posted an interesting reflection about the use of description languages on RESTful services. I have to agree 200% with Steve, WSDL and 1.1 and simply horrendous. Although WSDL 2.0 drastically improves in the modeling aspects of the services…(read more)
How To: Obtain a list of receive actions when an ASDK-based Adapter is used with BizTalk in a Receive Location
The WCF LOB Adapter SDK (ASDK) contains a behavior named “InboundActionEndpointBehavior” which you can add to your ServiceHost in inbound scenarios. What this behavior does is, at runtime, analyzes the contract deployed, determines the Actions on the Contract, and passes those to the adapter in the StartListener() call (on the IInboundHandler interface) via the “string[] actions” parameter. This allows the adapter to determine what actions the user is listening for, and send only messages of those type.
More information on this can be found at: http://blogs.msdn.com/sonuarora/archive/2007/06/11/passing-soap-actions-to-adapter-inbound-handler-for-filtering-type-of-listeners.aspx
What do you do when the adapter is used in a Receive Location from BizTalk? The WCF Adapter allows you specify endpoint behaviors for the ServiceHost which it creates, and that’s how you can plug in the InboundActionEndpointBehavior. However, this doesnt work as expected. Reason – the WCF Adapter uses an “untyped” contract for the Service, i.e., the Action/ReplyAction is specified as “*” / “*”. Hence, even if you add the endpoint behavior, the “string[] actions” array just contains “*”. How would a user let the adapter know what operations he is interested in?
Attached is a sample endpoint behavior which you can use. The primary difference between this behavior and the one which ships with ASDK is this – the ASDK behavior determines the list of actions from the deployed contract, and passes those to the adapter. On the other hand, the sample endpoint behavior (attached) gets the list of actions via user input. That is, while configuring your receive location, add this endpoint behavior (via the behaviors tab), and you’ll see two properties: “receiveActions” and “delimiter”. You need to concatenate all the actions into a single string and set it on the “receiveActions” property. Also, specify the delimiter you used in the “delimiter” property. The behavior will then split the concatenated string into a list of actions, store them in an ASDK specific class, and add this object to the Binding Parameter Collection. ASDK will then pick out the actions from there and pass them to the adapter in the StartListener call.
The attached .cs file contains comments towards the top of the file detailing how it needs to be compiled, and what entries need to be made in machine.config.
How To: Obtain a list of receive actions when an ASDK-based Adapter is used with BizTalk in a Receive Location
The WCF LOB Adapter SDK (ASDK) contains a behavior named “InboundActionEndpointBehavior” which you can add to your ServiceHost in inbound scenarios. What this behavior does is, at runtime, analyzes the contract deployed, determines the Actions on the Contract, and passes those to the adapter in the StartListener() call (on the IInboundHandler interface) via the “string[] actions” parameter. This allows the adapter to determine what actions the user is listening for, and send only messages of those type.
More information on this can be found at: http://blogs.msdn.com/sonuarora/archive/2007/06/11/passing-soap-actions-to-adapter-inbound-handler-for-filtering-type-of-listeners.aspx
What do you do when the adapter is used in a Receive Location from BizTalk? The WCF Adapter allows you specify endpoint behaviors for the ServiceHost which it creates, and that’s how you can plug in the InboundActionEndpointBehavior. However, this doesnt work as expected. Reason – the WCF Adapter uses an “untyped” contract for the Service, i.e., the Action/ReplyAction is specified as “*” / “*”. Hence, even if you add the endpoint behavior, the “string[] actions” array just contains “*”. How would a user let the adapter know what operations he is interested in?
Attached is a sample endpoint behavior which you can use. The primary difference between this behavior and the one which ships with ASDK is this – the ASDK behavior determines the list of actions from the deployed contract, and passes those to the adapter. On the other hand, the sample endpoint behavior (attached) gets the list of actions via user input. That is, while configuring your receive location, add this endpoint behavior (via the behaviors tab), and you’ll see two properties: “receiveActions” and “delimiter”. You need to concatenate all the actions into a single string and set it on the “receiveActions” property. Also, specify the delimiter you used in the “delimiter” property. The behavior will then split the concatenated string into a list of actions, store them in an ASDK specific class, and add this object to the Binding Parameter Collection. ASDK will then pick out the actions from there and pass them to the adapter in the StartListener call.
The attached .cs file contains comments towards the top of the file detailing how it needs to be compiled, and what entries need to be made in machine.config.
Applying Role-Based Security to BizTalk Feeds From RSSBus
I recently showed how one could use RSSBus to generate RSS feeds for BizTalk service metrics on an application-by-application basis. The last mile, for me, was getting security applied to a given feed. I only have a single file that generates all the feeds, but, I still need to apply role-based security restraints on the […]