by community-syndication | Dec 11, 2006 | BizTalk Community Blogs via Syndication
I am happy to see this progress:
The Web Services Interoperability Organization (WS-I) announced the publication of three new Working Group Drafts: the Basic Profile 1.2, Basic Security Profile 1.1 and the Reliable Secure Profile 1.0 Usage Scenarios. Advancement of these documents to Working Group Draft status is an invitation to the Web services community to provide technical feedback.
by stephen-w-thomas | Dec 11, 2006 | Stephen's BizTalk and Integration Blog
I have updated the BizTalk Bloggers OPML file. This update adds about 6 new BizTalk related blogs bringing the total to 97.
You can download the OPML file here.
If you do not want to track the blogs yourself, you can see most of them online on our syndicated blog site. Currently, Community Server does not support ATOM feeds. So the blogs that only have ATOM feeds will not show up.
by community-syndication | Dec 11, 2006 | BizTalk Community Blogs via Syndication
I’ve just made an update to the R1 BETA release. Now instead of the multiple MSI’s, the source code is packaged in a simple zip file and the bindings to source control have been removed. This should make this easier to use in your own directory structures. Also note that the Altova XML package has been removed from this download although it is still a pre-requisite to compile the package. If you do not wish to use AltovaXMlLremove the step from your copy of the source code.
by community-syndication | Dec 11, 2006 | BizTalk Community Blogs via Syndication
On his website at xkcd.com, Randall Munroe has an excellent ‘comic’ map of the IPv4 address space.
The map shows 256 numbered blocks each representing one /8 subnet of the available IP address space. Of particular interest are the blocks sold directly to governments and companies in the early 1990’s before the Regional Internet Registries took […]
by community-syndication | Dec 11, 2006 | BizTalk Community Blogs via Syndication
Buried deep down in one of the Install Guides (multiserver, pg 23) I came across a
section that shows you where to change the BAM alert email formats.
Basically there are two files – emailNotification.xslt and fileNotification.xslt both
found in the …\Microsoft BizTalk Server 2006\Tracking directory.
If you want to split the function of BAM alerting to different machines (the Provider,
Generator and Distributor within the Notification Services) then there’s a little
step you need to do, to tell the BAM Alerting Event Provider where these new XSLT
files are.
Within the Tracking Dir:
1. Run ProcessBAMNsFiles.vbs – this creates a *.adf file.
2. Edit the *.adf file to point to the new names/location of your modified *.xslt
files.
3. ReRun ProcessBAMNsFiles.vbs so it picks up the modified *.adf
file and makes the changes to the BizTalk Runtime.
4. Restart the BAMAlerts Windows Service.
Handy one – especially being able to modify those emails.
by community-syndication | Dec 11, 2006 | BizTalk Community Blogs via Syndication
I have uploaded an update to the BizTalkGurus.com BizTalk Bloggers OPML file. This update adds 6 new BizTalk related blogs and brings the total to 97.
You can download the OPML file here.
If you do not want to track the blogs yourself, you can see most of the blog content online on the syndicated blog site. Currently, Community Server does not support ATOM feeds. So the blogs that only have ATOM feeds will not show up. Too bad since some of the best BizTalk blogs are on Blogger.
by Richard | Dec 11, 2006 | BizTalk Community Blogs via Syndication
Understanding Xpath expressions is definitely a success factor when working with BizTalk development. Xpath is extremely powerful (when one gets it right) but it’s one of the must frustration techniques I’ve ever worked with! Xpath is one of those languages that either gives you to answer you want to a query – or (more often) just doesn’t give you anything in return! In 99 percent of the cases this means that you missed something in your match. In 99 percent of these cases this means that you got some problems with namespaces in the XML document your querying (This is certainly true when working with BizTalk that “namespace-heavy”). One technique to get around this is to use the same approach as BizTalk itself uses – the Xpath local-name() function!
Consider the following XML document.
<div><span style="color: #0000FF; "><</span><span style="color: #800000; ">Message </span><span style="color: #FF0000; ">xmlns:ns0</span><span style="color: #0000FF; ">="Standard.Envelope/1.1"</span><span style="color: #FF0000; "> xmlns:xsi</span><span style="color: #0000FF; ">="http://www.w3.org/2001/XMLSchema-instance"</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "><</span><span style="color: #800000; ">ns0:Envelope</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "><</span><span style="color: #800000; ">Header</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "><</span><span style="color: #800000; ">MessageTypeInfo</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "><</span><span style="color: #800000; ">MessageType</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">.</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">MessageType</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">MessageTypeInfo</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "><</span><span style="color: #800000; ">Action</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">INSERTED</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">Action</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "><</span><span style="color: #800000; ">Addressees</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "><</span><span style="color: #800000; ">SenderCode</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">Mill</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">SenderCode</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">Addressees</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">Header</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">ns0:Envelope</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">Message</span><span style="color: #0000FF; ">></span></div>
The Xpath expression below will hit the Envelope node. But is’s very fragile! As soon as the namespace prefix changes (It might change to ns1 and namespace ns0 will be used for something else.) you’ll end up with an empty result.
<div><span style="color: #000000; ">/Message/ns0:Envelope</span></div>
However, if one uses the below expressions instead – that makes use of the local-name function – it ignores the namespace and only cares about the name of the node (Envelope that is ;)). And this is of course far less sensitive to change.
<div><span style="color: #000000; ">/Message/*[local-name()='Envelope']</span></div>
by community-syndication | Dec 11, 2006 | BizTalk Community Blogs via Syndication
Understanding Xpath expressions is definitely a success factor when working with BizTalk development. Xpath is extremely powerful (when one gets it right) but it’s one of the must frustration techniques I’ve ever worked with! Xpath is one of those languages that either gives you to answer you want to a query – or (more often) just doesn’t […]
by Richard | Dec 11, 2006 | BizTalk Community Blogs via Syndication
I’m currently working in a stabilization phase on a deployment application for BizTalk 2006 projects. We based the solution on the Enterprise Solutions Build Framework and the BizTalk Explorer Object Model. Basically our solution has a GUI that makes it possible to point out which artifacts one likes to deploy (from the developers local BizTalk server).
The application then figures out all the dependencies that the selected artifacts has (In our solution an Orchestration for example might have > 20 dependencies to different schemas, pipelines, C# libraries etc, etc).
All DLL:s of the different artifacts are then extracted from the local GAC (where they exist when deployed to the local BizTalk). These DLL:s are then packed in to one single deployment package also containing a single XML file that keeps track of the dependencies and the order of witch they have to be deployed in BizTalk (the most depending schemas first and so on). The XML file also contains other meta data information such as ports the artifacts use etc.
This package is then loaded into another part of the application were it’s possible to point out the different servers one like to deploy to. This view then shows information about what has to be done on the server to make it possible to deploy without conflicts (One might have running Orchestration or suspended messages for example that has to be stopped or terminated.). At this stage we also check the naming of the different artifacts. These have to comply with the naming conventions that are configured in the config file of the applications (a warning is shown if the artifact doesn’t validate towards these).
When no warnings (its possible to override a warning) or conflicts are shown one can deploy. We then move the deploy scripts to the servers and use the MSBuild tasks in the SBF to deploy everything for us. We really saved some serious time with this approach and even if it took us a while to get everything working it’s been well worth it!
We have a huge feature list for the next phase of the tool and are planing to and support for BizUnit tests in the DLL:s (so that one gets a warning when deploying a Orchestration without etc). We also like to add more meta data about the port and make it possible to configure new ports as a part of the deployment process. Etc, etc …
Feel free to comment or write we line for further information about this approach. It would also be interesting to hear about other approaches for deployment and what kind of features these solutions have.
by community-syndication | Dec 11, 2006 | BizTalk Community Blogs via Syndication
I’m currently working in a stabilization phase on a deployment application for BizTalk 2006 projects. We based the solution on the Enterprise Solutions Build Framework and the BizTalk Explorer Object Model. Basically our solution has a GUI that makes it possible to point out which artifacts one likes to deploy (from the developers local BizTalk server).
The […]