Hi readers,
BizTalk 24 * 7 is down at the moment due to hardware failure at my ISP. They are currently working on the case. I’m trying whatever I can on my capacity to bring it back online ASAP.
Apologies for any inconvenience.
I’ll give you an update once the issue is fixed.
Nandri,
Saravana
Hi readers,
BizTalk 24 * 7 is down at the moment due to hardware failure at my ISP. They are currently working on the case. I’m trying whatever I can on my capacity to bring it back online ASAP.
Apologies for any inconvenience.
I’ll give you an update once the issue is fixed.
Nandri,
Saravana
The BizTalk Team anounced that a new poster, the BAM poster , will see the light of day. I really like the posters that have been released as companions to the BizTalk Server documentation. I'm not really the grapical guy, at least not when it comes…(read more)
The BizTalk Team anounced that a new poster, the BAM poster , will see the light of day. I really like the posters that have been released as companions to the BizTalk Server documentation. I'm not really the grapical guy, at least not when it comes…(read more)
I’ve been playing lately with a few WCF features as well as with the WCF Adapter in
BizTalk Server 2006 R2. As part of that I had a need to set up a receive location
using one of the WCF HTTP-based bindings.
Normally, this isn’t a big deal; you can easily use the BizTalk WCF Service Publishing
Wizard to create the receive location and IIS service application for an orchestration
or from a set of BizTalk schemas.
However, this time I did not want to go that way. What I really wanted was just a
simple receive location that would simply receive messages and submit them over to
BizTalk without tying the receive location to a specific service definition. As far
as I could see, the Service Publishing Wizard didn’t really have an option for this,
but I was confident it could be made to work.
To be honest, I did have a set of schemas I wanted to work with and even a bunch of
predefined WSDL files. However, for many reasons (including the sheer complexity of
the schemas and WSDL files involved) I didn’t want to get that involved in my initial
BizTalk message receiver and processor.
Fortunately, turns out that doing what I wanted was fairly easy stuff. In fact, it
was so easy that was able to leverage an existing service I had previously created.
I basically just copied the .SVC file (and renamed it) alongside the web.config file.
I explicitly ignored all the stuff that normally gets generated under the App_Data
directory.
I then manually created a matching receive location in BizTalk using the WCF-BasicHTTP
adapter, and this worked right away perfectly for my needs!
Just in case you’ve never looked at what a WCF HTTP receive location generated files
look like, it’s actually fairly simple stuff. The SVC file contains just a single
directive as expected:
<%@ ServiceHost
Language="c#" Factory="Microsoft.BizTalk.Adapter.Wcf.Runtime.BasicHttpWebServiceHostFactory,
Microsoft.BizTalk.Adapter.Wcf.Runtime, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
You can see here that it references the WCF-BasicHTTP adapter. If you wanted to use,
say, the WCF-WSHttp Adapter, then you’d use Microsoft.BizTalk.Adapter.Wcf.Runtime.WSHttpWebServiceHostFactory class
instead.
The config file is pretty much the default config file generated by the Service Publishing
Wizard as well:
<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<configSections>
<section
name="bizTalkSettings"
type="Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkConfigurationSection,
Microsoft.BizTalk.Adapter.Wcf.Runtime, Version=3.0.1.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</configSections>
<bizTalkSettings>
<mexServiceHostFactory debug="false">
<receiveLocationMappings>
<!--add
markupFileName="*.svc"
receiveLocationName="?"
publicBaseAddress="protocol://host[:port]" /-->
</receiveLocationMappings>
</mexServiceHostFactory>
<webServiceHostFactory debug="false" />
<isolatedReceiver disable="false" />
<btsWsdlExporter disable="false" />
</bizTalkSettings>
<appSettings />
<connectionStrings />
<system.web>
<compilation defaultLanguage="c#" debug="false">
<assemblies>
<add assembly="mscorlib,
version=2.0.0.0, culture=neutral,
publickeytoken=b77a5c561934e089" />
<add assembly="Microsoft.BizTalk.Adapter.Wcf.Common,
Version=3.0.1.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add assembly="Microsoft.BizTalk.Adapter.Wcf.Runtime,
Version=3.0.1.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</assemblies>
</compilation>
<authentication mode="Windows" />
</system.web>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehaviorConfiguration">
<serviceDebug
httpHelpPageEnabled="true"
httpsHelpPageEnabled="false"
includeExceptionDetailInFaults="false" />
<serviceMetadata
httpGetEnabled="false"
httpsGetEnabled="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service
name="Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance"
behaviorConfiguration="ServiceBehaviorConfiguration">
<!--<endpoint
name="HttpMexEndpoint"
address="mex"
binding="mexHttpBinding"
bindingConfiguration=""
contract="IMetadataExchange" />-->
<!--<endpoint
name="HttpsMexEndpoint"
address="mex"
binding="mexHttpsBinding"
bindingConfiguration=""
contract="IMetadataExchange" />-->
</service>
</services>
</system.serviceModel>
</configuration>
It’s extremely nice to see how the WCF adapter in BizTalk leverages a bunch of my
favorite features in WCF to make this a lot simpler (compared to, say, the whole bunch
of code that needed to be generated for the original SOAP adapter).
I should mention though, that part of what made it so easy was that my needs were
pretty simple: I wanted a simple two-way (request/response) port, and needed no metadata
(WSDL) publishing at all (as I said, I already had working WSDL files I could provide
to consumers of the service). Making it one-way wouldn’t have been a problem
though; as the WCF adapter handles it very gracefully as well.
WCF, BizTalk
I’ve been playing lately with a few WCF features as well as with the WCF Adapter in
BizTalk Server 2006 R2. As part of that I had a need to set up a receive location
using one of the WCF HTTP-based bindings.
Normally, this isn’t a big deal; you can easily use the BizTalk WCF Service Publishing
Wizard to create the receive location and IIS service application for an orchestration
or from a set of BizTalk schemas.
However, this time I did not want to go that way. What I really wanted was just a
simple receive location that would simply receive messages and submit them over to
BizTalk without tying the receive location to a specific service definition. As far
as I could see, the Service Publishing Wizard didn’t really have an option for this,
but I was confident it could be made to work.
To be honest, I did have a set of schemas I wanted to work with and even a bunch of
predefined WSDL files. However, for many reasons (including the sheer complexity of
the schemas and WSDL files involved) I didn’t want to get that involved in my initial
BizTalk message receiver and processor.
Fortunately, turns out that doing what I wanted was fairly easy stuff. In fact, it
was so easy that was able to leverage an existing service I had previously created.
I basically just copied the .SVC file (and renamed it) alongside the web.config file.
I explicitly ignored all the stuff that normally gets generated under the App_Data
directory.
I then manually created a matching receive location in BizTalk using the WCF-BasicHTTP
adapter, and this worked right away perfectly for my needs!
Just in case you’ve never looked at what a WCF HTTP receive location generated files
look like, it’s actually fairly simple stuff. The SVC file contains just a single
directive as expected:
<%@ ServiceHost
Language="c#" Factory="Microsoft.BizTalk.Adapter.Wcf.Runtime.BasicHttpWebServiceHostFactory,
Microsoft.BizTalk.Adapter.Wcf.Runtime, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
You can see here that it references the WCF-BasicHTTP adapter. If you wanted to use,
say, the WCF-WSHttp Adapter, then you’d use Microsoft.BizTalk.Adapter.Wcf.Runtime.WSHttpWebServiceHostFactory class
instead.
The config file is pretty much the default config file generated by the Service Publishing
Wizard as well:
<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<configSections>
<section
name="bizTalkSettings"
type="Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkConfigurationSection,
Microsoft.BizTalk.Adapter.Wcf.Runtime, Version=3.0.1.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</configSections>
<bizTalkSettings>
<mexServiceHostFactory debug="false">
<receiveLocationMappings>
<!--add
markupFileName="*.svc"
receiveLocationName="?"
publicBaseAddress="protocol://host[:port]" /-->
</receiveLocationMappings>
</mexServiceHostFactory>
<webServiceHostFactory debug="false" />
<isolatedReceiver disable="false" />
<btsWsdlExporter disable="false" />
</bizTalkSettings>
<appSettings />
<connectionStrings />
<system.web>
<compilation defaultLanguage="c#" debug="false">
<assemblies>
<add assembly="mscorlib,
version=2.0.0.0, culture=neutral,
publickeytoken=b77a5c561934e089" />
<add assembly="Microsoft.BizTalk.Adapter.Wcf.Common,
Version=3.0.1.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add assembly="Microsoft.BizTalk.Adapter.Wcf.Runtime,
Version=3.0.1.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</assemblies>
</compilation>
<authentication mode="Windows" />
</system.web>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehaviorConfiguration">
<serviceDebug
httpHelpPageEnabled="true"
httpsHelpPageEnabled="false"
includeExceptionDetailInFaults="false" />
<serviceMetadata
httpGetEnabled="false"
httpsGetEnabled="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service
name="Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance"
behaviorConfiguration="ServiceBehaviorConfiguration">
<!--<endpoint
name="HttpMexEndpoint"
address="mex"
binding="mexHttpBinding"
bindingConfiguration=""
contract="IMetadataExchange" />-->
<!--<endpoint
name="HttpsMexEndpoint"
address="mex"
binding="mexHttpsBinding"
bindingConfiguration=""
contract="IMetadataExchange" />-->
</service>
</services>
</system.serviceModel>
</configuration>
It’s extremely nice to see how the WCF adapter in BizTalk leverages a bunch of my
favorite features in WCF to make this a lot simpler (compared to, say, the whole bunch
of code that needed to be generated for the original SOAP adapter).
I should mention though, that part of what made it so easy was that my needs were
pretty simple: I wanted a simple two-way (request/response) port, and needed no metadata
(WSDL) publishing at all (as I said, I already had working WSDL files I could provide
to consumers of the service). Making it one-way wouldn’t have been a problem
though; as the WCF adapter handles it very gracefully as well.
WCF, BizTalkI’m glad to announce the latest addition to our BizTalk posters series. We have just published the new BizTalk Server 2006 R2 Business Activity Monitoring (BAM) Poster. You can find it in the Microsoft download center here.
This poster provides an overview of the entire life cycle of a BizTalk BAM implementation. It illustrates the design of the observation model by the business analyst, mapping the observation model to the implementation by the developer, deployment by the system administrator, and the presentation channels of the information for business end users.
We hope to promote the usage of the BizTalk BAM infrastructure by enabling both new and experienced users to better understand the concepts, processes it entails.
Enjoy it,
Ofer
I’m glad to announce the latest addition to our BizTalk posters series. We have just published the new BizTalk Server 2006 R2 Business Activity Monitoring (BAM) Poster. You can find it in the Microsoft download center here.
This poster provides an overview of the entire life cycle of a BizTalk BAM implementation. It illustrates the design of the observation model by the business analyst, mapping the observation model to the implementation by the developer, deployment by the system administrator, and the presentation channels of the information for business end users.
We hope to promote the usage of the BizTalk BAM infrastructure by enabling both new and experienced users to better understand the concepts, processes it entails.
Enjoy it,
Ofer
So the documentation that comes with the BizTalk Adapter Pack makes scant reference to flowing transactions to the adapters. That is, if I want to call the “Insert” operation on an “Orders” table, but only commit that if the “Insert” operation on the “Order Items” table succeeds, how do I wrap those operations in a […]
So the documentation that comes with the BizTalk Adapter Pack makes scant reference to flowing transactions to the adapters. That is, if I want to call the “Insert” operation on an “Orders” table, but only commit that if the “Insert” operation on the “Order Items” table succeeds, how do I wrap those operations in a […]