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 […]
Richard Seroter published useful utility to store/retrieve configuration settings in Enterprise SSO database. I added some more functionality to it.
First, I added Export/Import functions allowing to actually save values in the external XML file (Richard’s implementation allowed storing only field names, calling for extra work should you delete and restore SSO aplication). I kept file format the same so the usage scenarios are:
Saving configuration: 1.1 Create application; 1.2 Save to XML; 1.3 Manage application – Retrieve settings; 1.4 Export to XML file created in (1.2).
Restoring previously saved configuration: 2.1 Create application; 2.2 Manage application – Import configuration from file created in (1.4) ; 2.3 Save Changes.
Accordingly, menu items Import/Export available when the Manage Application tab is selected only.
The second part of improvement is where I failed. I added “Select Application” button on the Manage Application tab to browse for available applications in SSO database. Currently, it won’t find any ConfigStore application it will come back with “No Applications Found” message. I left this button on intentionally hoping that some would help me to solve this problem. It appears that neither ISSOMapper nor ISSOMapper2 return list of ConfigStore type SSO application. This API call will return application of types Individual, Group or Host Group but not ConfigStore which is the one we create using this tool. At least with the SSOFlag combination being set (0x140006). I tried different flag combinations but could not make it work. So please let me know.
The code can be downloaded here.
Richard Seroter published useful utility to store/retrieve configuration settings in Enterprise SSO database. I added some more functionality to it.
First, I added Export/Import functions allowing to actually save values in the external XML file (Richard’s implementation allowed storing only field names, calling for extra work should you delete and restore SSO aplication). I kept file format the same so the usage scenarios are:
Saving configuration: 1.1 Create application; 1.2 Save to XML; 1.3 Manage application – Retrieve settings; 1.4 Export to XML file created in (1.2).
Restoring previously saved configuration: 2.1 Create application; 2.2 Manage application – Import configuration from file created in (1.4) ; 2.3 Save Changes.
Accordingly, menu items Import/Export available when the Manage Application tab is selected only.
The second part of improvement is where I failed. I added “Select Application” button on the Manage Application tab to browse for available applications in SSO database. Currently, it won’t find any ConfigStore application it will come back with “No Applications Found” message. I left this button on intentionally hoping that some would help me to solve this problem. It appears that neither ISSOMapper nor ISSOMapper2 return list of ConfigStore type SSO application. This API call will return application of types Individual, Group or Host Group but not ConfigStore which is the one we create using this tool. At least with the SSOFlag combination being set (0x140006). I tried different flag combinations but could not make it work. So please let me know.
The code can be downloaded here.
I've previously posted my ideas about using LINQ in BizTalk . At that point it was just theories, and following the links in the comments section of that post I wasn't the first to have them. Thanks to the red bits/green bits approach BizTalk…(read more)