by community-syndication | Jul 1, 2006 | BizTalk Community Blogs via Syndication
This particular serialization problem took 2 midnight sessions to sort out. We had some untyped orchs published as webservices inside the service boundary and we were building a strong typed ASMX gateway as the service boundary. We used WSCF to generate the ASMX and used all the schemas that were inside the orchestrations so that we didnt have to maintain two different sets of messages. We then came across 2 problems, the first one more easily solved than the other. I’ll explain them below
(1)Duplicate namespaces: When you define a set of schemas in Biztalk, it is perfectly acceptable to define a common target namespace for example http://mycompany/schemas/services/customerservice and then to have different messages with specific root elements such as CreateCustomer, UpdateCustomer and so on. When biztalk recieves the message and validates them and works out the subscriptions, it adds the root element onto the target namespace making it http://mycompany/schemas/services/customerservice#CreateCustomer (note the # before the suffix) and this is enough for it to resolve most schemas. However, if you put all these Create, Update and Delete methods in your ASMX, then when you add a web reference, the .NET system crashes complaining of duplicate namespaces. Actually, the WSCF tool complained about duplicate namespaces even while creating the ASMX so we bypassed it and coded the ASMX ourselves (not realising it was right in complaining). This stumped us for a while, but it looks like this is default behavior in .NET and Biztalk has the ability to handle it but not the normal .NET framework which is fine. So we worked around it by changing the targetNamespace in all our schemas to have some extra phrases such as create, update and delete. Of course, if you put these kind of suffixes into the targetNamespace for biztalk its not a problem at all and it is then guaranteed to work in ordinary ASMX as well.
(2) Serialization and Precompilation: The second problem was much more involved. Once we finished revising the namespaces, we called the webservice only to get a nasty error message saying “File not found exception. System cannot find the file “xyz123”.dll (some arbitrary constantly changing name) . We tried setting all sorts of permissions everywhere and it didnt solve the problem. We narrowed it down to the serializer since ordinary webservice calls not involving complex types were working fine and since the webservice was writing to our debug log files we knew that the system wasnt even invoking the webservice. Finally we saw a post where someone recommended that we use Chris Sells’ XmlPrecompiler tool and the associated GUI built by Matthew Nolton. We then used the WSCF tool to generate a bunch of classes corresponding to the schema and checked them out. By this time i had also narrowed down the problem to a particular set of webmethods and one in particular where returning a void worked fine but returning a strong type caused the crash. Now the tool worked perfectly and crashed at the offending type. On close examination we found that by mistake, someone had created an array of arrays. (ie) we were returning an element called References and in that we needed unbounded elements named Reference with some attributes. It turned out that References had also been declared as unbounded. To add to this the namespaces were a bit muddled up and i read an article on MSDN saying that unqualified attributes in array types cause problems (or something to that effect). Anyway, i basically rewrote the schema to ensure all the elements were qualified correctly, corrected the ‘unbounded’ element and then it worked fine. There were also other schemas that dealt with arrays where the namespaces had to be reworked, but in the end it all worked fine.
This is a problem that one doesnt mind spending a couple of late nights working through eh? Who would have thought it would come down to finding a precompilation tool and sorting out the bug. So there it is… be very careful with schema definitions and arrays and use the precompiler tool as part of your quality checks. It will save a lot of tears and gain you some sleep as well.
by community-syndication | Jul 1, 2006 | BizTalk Community Blogs via Syndication
Whew.. this is a record for me. Two posts in the same day. Well, it has been a rather busy weekend trying to sort out my new laptop and make some progress on a serialisation issue i’ve been having. Thought i’d post about it cos it might make interesting reading for any Biztalkers in a similar situation out there. It also looks like this issue is still floating around on newsgroup posts (in fact I just came across my post on this subject last year and nothing much has happened since then). …(read more)
by community-syndication | Jun 30, 2006 | BizTalk Community Blogs via Syndication
I’ve seen this issue showing a couple of times on the BizTalk Newsgroups so I thought it’s worth posting about this on my blog. The user expectation, which is probably correct from usability point of view, is that the %Filename% macro is replaced with the name of the original file no matter if that file was received from the disk through FILE adapter or from a document library through SharePoint adapter. This doesn’t happen like that since the WSS adapter send ports will resolve the %Filename% macro to empty string if the message was originally received from any other adapter than WSS adapter. This is by design.
The %Filename% macro is replaced with the name of the SharePoint file (and not with the name of a file on disk). If the message was received through FILE adapter (or any other adapter than WSS) then the %Filename% macro is probably replaced with empty string. Macros (like %Filename%) and context properties (like WSS.Filename) are implemented by each adapter separately, they are specific to each adapter, and there is no ‘framework’ that would provide a unified set of macros/context properties accross all adapters. This makes sense since ‘%Filename%’ might not make sense for a POP3 adapter or it could have a slightly different behavior for 3rd party adapters. Coincidently, some adapters have used the same macro name (I would guess %Filename% is a common one) and ocasionally the same context property. However, the %Filename% macro in a WSS adapter send port is totally different from a %Filename% macro in an FTP adapter send port, for instance.
To workaround this you can use an orchestration or a custom pipeline. All you need to do is get the disk file name from FILE.ReceivedFileName property and save it in the WSS.Filename property like below. Make sure that the Filename field in the send port UI dialog box is left empty so that the value supplied through the context property WSS.Filename is used to set the filename.
sharepointOutgoingMsg(WSS.Filename) = diskIncomingMsg(FILE.ReceivedFileName);
http://msdn.microsoft.com/library/en-us/BTS06Operations/html/1ff50fb8-7ba0-47b8-9476-d57413989346.asp?frame=true
http://msdn.microsoft.com/library/en-us/BTS06Operations/html/c5ae5339-67bf-4fde-a721-5b1aa3b9caca.asp?frame=true
You don’t have to use dynamic send ports for the workaround above. In the case of WSS adapter, you can define the send port configuration through the WSS.Config*, WSS.Filename context properties of the outgoing message and then configure the WSS send port equivalent properties so that they are either empty (text boxes) or have a value of Orchestration (drop-down boxes) in order to not overwrite the configuration information specified through the context properties.
by community-syndication | Jun 30, 2006 | BizTalk Community Blogs via Syndication
(Update: The original download files were missing the PDB-to-GAC functionality
I’ve discussed before. Please download again if you have already…)
The BizTalk
Deployment Framework has been updated to work with BizTalk 2006…It is hard to
believe that this project has been going on since May of 2004!
The Deployment Framework for BizTalk 2006 still has the same goals as the
2004 version:
-
Streamline the deployment process for developers, ensuring repeatability
-
Make it easier for a team of BizTalk developers to stay in sync – not just with BizTalk
artifacts, but with all the other infrastructure that surrounds the solution (virtual
directories, queues, file folders, etc.)
-
Extremely close parity between server-side deployments and developer deployments –
so you are always testing your server deployments as you go through a typical developer
work day.
BizTalk 2006 itself introduced quite a few features to make deployment easier, and
can work fine for small (or solo) projects. Here are a few limitations I’ve
encountered:
-
Though much improved, it is still possible to get into “dependency chaos” – where
you spend time manually undeploying/deploying individual artifacts.
-
Binding changes have to be communicated “manually” between developers on a team, since
the import process is done through the Admin MMC or command-line. Just “getting
latest” from version control isn’t sufficient.
-
Binding files for your various environments have to be maintained as separate files
(manually), rather than “merging in” environment-specific settings
-
Artifacts such as rules, virtual directories, queues, folders, additional dependent
assemblies, etc. can be represented as “Resources” within the Admin MMC (and in exported
MSIs), but not in a fashion that easily moves between developers on a team.
So! To get started with this version, download the Deployment
Framework (Tools) zip and run the MakeBizTalkExternalTools_VS2005.vbs script.
This will add entries to the Visual Studio tools menu for deploying and undeploying
using the framework. You can download the full
sample to see the framework in action (first build it, then do Tools-BizTalk
Deploy. You’ll see something like this.)
The high-level approach is the same as the 2004 framework – you supply a small project-specific
NAnt script that indicates via properties what elements of a deployment your solution
requires. You include BizTalkDeploymentInclude.nant to get all the core deployment functionality,
and make sure the DeployTools directory is copied to your project. (Unzipping
the Deployment
Framework Core into your project is a good way to do this.) See the documentation for
a more complete discussion.
The primary difference in the upgraded framework for BizTalk 2006 is that
we now create a BizTalk Application definition, and use BTSTask to
add all BizTalk artifacts as resources within that application. Starting and
stopping the application is done at an application level rather than per port/per
orchestration.
Packaging up your solution as an MSI can be done with the WiX-based scripts that have
been in the framework for awhile, or by using the MSI export mechanism in
BizTalk 2006, if you prefer. (The latter solution will require a few additional
steps, and doesn’t give you the parity described earlier. But it works if you
need to go that route.)
Other Notes:
-
NAnt
.85 RC4 (and NAntContrib )
is required. Be sure to copy the new BizTalk.NAnt.Tasks.dll to NAnt’s bin directory.
We need to call BizTalk’s .net 2.0 assemblies, and NAnt wasn’t built against 2.0 —
so change nant.exe.config to have only<supportedRuntime version=”v2.0.50727″
/> in the<startup> element.
-
Log4net usage in the sample (which isn’t required of course for the framework)
has been updated to log4net
1.2.10 , as has my serializable
wrapper. You can find the new log4net.Ext.Serializable in the Tools download
(which is useful all by itself, apart from the framework.)
-
You can actually use the BizTalkDeploymentInclude.nant file in this release with BizTalk
2004, if you like, to aid in your migration. There is NAnt property to indicate
2004 vs. 2006.
-
Scan all the previous
release notes…
Leave comments with any questions/issues/etc. Enjoy!
Download: Full
Sample, Framework
Core, Tools
Source , Docs
by community-syndication | Jun 30, 2006 | BizTalk Community Blogs via Syndication
(Update: The original download files were missing the PDB-to-GAC functionality
I’ve discussed before. Please download again if you have already…)
The BizTalk
Deployment Framework has been updated to work with BizTalk 2006…It is hard to
believe that this project has been going on since May of 2004!
The Deployment Framework for BizTalk 2006 still has the same goals as the
2004 version:
-
Streamline the deployment process for developers, ensuring repeatability
-
Make it easier for a team of BizTalk developers to stay in sync – not just with BizTalk
artifacts, but with all the other infrastructure that surrounds the solution (virtual
directories, queues, file folders, etc.)
-
Extremely close parity between server-side deployments and developer deployments –
so you are always testing your server deployments as you go through a typical developer
work day.
BizTalk 2006 itself introduced quite a few features to make deployment easier, and
can work fine for small (or solo) projects. Here are a few limitations I’ve
encountered:
-
Though much improved, it is still possible to get into “dependency chaos” – where
you spend time manually undeploying/deploying individual artifacts.
-
Binding changes have to be communicated “manually” between developers on a team, since
the import process is done through the Admin MMC or command-line. Just “getting
latest” from version control isn’t sufficient.
-
Binding files for your various environments have to be maintained as separate files
(manually), rather than “merging in” environment-specific settings
-
Artifacts such as rules, virtual directories, queues, folders, additional dependent
assemblies, etc. can be represented as “Resources” within the Admin MMC (and in exported
MSIs), but not in a fashion that easily moves between developers on a team.
So! To get started with this version, download the Deployment
Framework (Tools) zip and run the MakeBizTalkExternalTools_VS2005.vbs script.
This will add entries to the Visual Studio tools menu for deploying and undeploying
using the framework. You can download the full
sample to see the framework in action (first build it, then do Tools-BizTalk
Deploy. You’ll see something like this.)
The high-level approach is the same as the 2004 framework – you supply a small project-specific
NAnt script that indicates via properties what elements of a deployment your solution
requires. You include BizTalkDeploymentInclude.nant to get all the core deployment functionality,
and make sure the DeployTools directory is copied to your project. (Unzipping
the Deployment
Framework Core into your project is a good way to do this.) See the documentation for
a more complete discussion.
The primary difference in the upgraded framework for BizTalk 2006 is that
we now create a BizTalk Application definition, and use BTSTask to
add all BizTalk artifacts as resources within that application. Starting and
stopping the application is done at an application level rather than per port/per
orchestration.
Packaging up your solution as an MSI can be done with the WiX-based scripts that have
been in the framework for awhile, or by using the MSI export mechanism in
BizTalk 2006, if you prefer. (The latter solution will require a few additional
steps, and doesn’t give you the parity described earlier. But it works if you
need to go that route.)
Other Notes:
-
NAnt
.85 RC4 (and NAntContrib )
is required. Be sure to copy the new BizTalk.NAnt.Tasks.dll to NAnt’s bin directory.
We need to call BizTalk’s .net 2.0 assemblies, and NAnt wasn’t built against 2.0 —
so change nant.exe.config to have only<supportedRuntime version=”v2.0.50727″
/> in the<startup> element.
-
Log4net usage in the sample (which isn’t required of course for the framework)
has been updated to log4net
1.2.10 , as has my serializable
wrapper. You can find the new log4net.Ext.Serializable in the Tools download
(which is useful all by itself, apart from the framework.)
-
You can actually use the BizTalkDeploymentInclude.nant file in this release with BizTalk
2004, if you like, to aid in your migration. There is NAnt property to indicate
2004 vs. 2006.
-
Scan all the previous
release notes…
Leave comments with any questions/issues/etc. Enjoy!
Download: Full
Sample, Framework
Core, Tools
Source , Docs
by community-syndication | Jun 30, 2006 | BizTalk Community Blogs via Syndication
I’ve seen this issue showing a couple of times on the BizTalk Newsgroups so I thought it’s worth posting about this on my blog. The user expectation, which is probably correct from usability point of view, is that the %Filename% macro is replaced with the name of the original file no matter if that file was received from the disk through FILE adapter or from a document library through SharePoint adapter. This doesn’t happen like that since the WSS adapter send ports will resolve the %Filename% macro to empty string if the message was originally received from any other adapter than WSS adapter. This is by design.
The %Filename% macro is replaced with the name of the SharePoint file (and not with the name of a file on disk). If the message was received through FILE adapter (or any other adapter than WSS) then the %Filename% macro is probably replaced with empty string. Macros (like %Filename%) and context properties (like WSS.Filename) are implemented by each adapter separately, they are specific to each adapter, and there is no ‘framework’ that would provide a unified set of macros/context properties accross all adapters. This makes sense since ‘%Filename%’ might not make sense for a POP3 adapter or it could have a slightly different behavior for 3rd party adapters. Coincidently, some adapters have used the same macro name (I would guess %Filename% is a common one) and ocasionally the same context property. However, the %Filename% macro in a WSS adapter send port is totally different from a %Filename% macro in an FTP adapter send port, for instance.
To workaround this you can use an orchestration or a custom pipeline. All you need to do is get the disk file name from FILE.ReceivedFileName property and save it in the WSS.Filename property like below. Make sure that the Filename field in the send port UI dialog box is left empty so that the value supplied through the context property WSS.Filename is used to set the filename.
sharepointOutgoingMsg(WSS.Filename) = diskIncomingMsg(FILE.ReceivedFileName);
http://msdn.microsoft.com/library/en-us/BTS06Operations/html/1ff50fb8-7ba0-47b8-9476-d57413989346.asp?frame=true
http://msdn.microsoft.com/library/en-us/BTS06Operations/html/c5ae5339-67bf-4fde-a721-5b1aa3b9caca.asp?frame=true
You don’t have to use dynamic send ports for the workaround above. In the case of WSS adapter, you can define the send port configuration through the WSS.Config*, WSS.Filename context properties of the outgoing message and then configure the WSS send port equivalent properties so that they are either empty (text boxes) or have a value of Orchestration (drop-down boxes) in order to not overwrite the configuration information specified through the context properties.
by community-syndication | Jun 30, 2006 | BizTalk Community Blogs via Syndication
Astute browsers of the blog have noticed that we’ve changed the name of the October conference. It is now known as the Microsoft SOA and Business Process Conference. Why’d we do that? Well that’s an interesting story. It seems some people think that Microsoft doesn’t do SOA. Well not people per se; some press, analysts and BDM’s (marketing speak for business decision maker, or your bosses, bosses, boss) only believe in talk. Walking the walk isn’t true until you yell your message at the top of your voice.
As the loyal BizTalker’s reading the blog know the Microsoft technology stack is service oriented from top to bottom. From Windows Vista (.NET Fx 3.0) through 2007 Office System (XML file formats) to SharePoint (Web Service enabled) down to BizTalk, SQL Server and Windows Server itself, Service Orientation is baked in. It’s in the platform, silly.
Microsoft’s SOA story isn’t secret sauce locked up in the heads of suited consultants or hiding inside the box of ’out of this world’ costly software packages. It’s out in the open. It’s there in Visual Studio for developers to unleash. It’s in Operations Manager for IT to harness and it’s in Internet Explorer and ASP .NET/Atlas for the world to mash up. Architectural guidance is plainly in view on MSDN (well if you can get the query right in the search engine it is :^). Microsoft partners build SOA solutions every single day.
Yelling “SOA” at the top of our voices seems redundant, so we won’t do that. But if explicitly discussing real capabilities that any of us can use is your idea of ’talking the talk’ then the Microsoft SOA and Business Process Conference is the show for you. We on the BizTalk team will make sure to invite some press and analysts and you can bring your BDM. Let’s nip this nasty FUD in the bud.
The conference track abstracts will go up on the site next week as will a call for sessions to interested presenters. Shortly after that we’ll post the session abstracts themselves.
Remember the early bird registration discount is available through July 21st. You can register for the show at http://impactevents.com/biztalkconference/
Regards,
mike
by community-syndication | Jun 29, 2006 | BizTalk Community Blogs via Syndication
What Kris said…
http://blogs.msdn.com/biztalk_server_team_blog/archive/2006/06/29/650328.aspx
Check out the attached doc there!
by community-syndication | Jun 29, 2006 | BizTalk Community Blogs via Syndication
Fresh new goodies on the Microsoft Download site:
Windows SharePoint Services V3 Starter Kit: Workflow Developer Starter Kit for Windows SharePoint Services V3
The Workflow Developer Starter Kit for Microsoft%u00ae Windows%u00ae SharePoint%u00ae Services V3 (Beta 2) contains Microsoft%u00ae Visual Studio%u00ae project templates for workflow in Windows SharePoint Services V3 (Beta 2) and a sample custom workflow.
Visual Studio 2005 Tools for Office Update: InfoPath 2007 Beta Support
With this update to the Microsoft Office InfoPath 2003 Toolkit for Visual Studio 2005 as included in Microsoft Visual Studio 2005 for the Microsoft Office System, you can develop InfoPath 2007 forms inside Visual Studio.
Outlook 2007 Add-Ins: RulesAddin, TravelAgencyAddin, and PrepareMeAddin
The three sample add-ins provided in this download are available in both C# and Visual Basic .NET versions. They demonstrate many of the new and enhanced features of the Outlook object model.
by community-syndication | Jun 28, 2006 | BizTalk Community Blogs via Syndication
Wow, our User Experience team continues to amaze! They have just released an update to the BizTalk Server 2006 documentation that contains tons of new content. I’d list it all here, but there’s just too much so check out the attached doc for the full run down. Also, if you don’t already, you should monitor Luke’s blog to stay on top of the new samples, tutorials, and doc refreshes they keep pumping out.
-Kris
