by community-syndication | Nov 10, 2009 | BizTalk Community Blogs via Syndication
Everyone knows (read that as: should know 😉 that enabling the BizTalk jobs “Backup BizTalk Server” and “DTA Purge and Archive” is a good thing. Even on simple test machines, and perhaps (preferably) even on your developer laptop. What happens some times though is that, when you end up using the dump-to-disk approach, you fill up your disks. This happens because by default the BizTalk Backup and DTA Purge and Archive jobs doesn’t clean house. In your production and staging environments the “IT guys” will usually have your back in this case and make sure that doesn’t happen. For those environment where that isn’t the case here’s an easy to use script provided by our IT guys to help keep things tidy. It uses the forfiles statement as the bulk of its logic.
@echo off
set BACKUP_PATH=%1
set RET_INTERVAL=%2
if "%BACKUP_PATH%"=="" exit 1
if "%RET_INTERVAL%"=="" exit 1
Forfiles /P %BACKUP_PATH% /S /M *.BAK /D -%RET_INTERVAL% /C "cmd /C Del @path"
exit %ERRORLEVEL%
Now all you need to do is to call this script from somewhere. A suggestion might be from a SQL job. This way you configure the backup and the cleanup of the backup files from a single location. Like this:
exec xp_cmdshell 'script.cmd C:\Backup 4'
script.cmd should be the full path to your script, while C:\Backup should be the full path to your backup directory. Remember to surround paths by “ should they contain spaces. The 4 in this case says that any files 4 days and older will be removed. Schedule as you see fit.
by community-syndication | Nov 10, 2009 | BizTalk Community Blogs via Syndication
For people interested in both PowerShell and BizTalk, I just finished a getting started guide to introduce the basics of the PowerShell provider for BizTalk (version 1.0 beta). The guide can be downloaded from here.
Tagged: BizTalk, BizTalk Management, BizTalk tools, PowerShell 
by community-syndication | Nov 10, 2009 | BizTalk Community Blogs via Syndication
Due to technical issues, (well, me not reading my hotmail account or any Azure blogs actually) I had a slight “outage” on CloudCasts. The USA-Northwest Azure data centres closed, taking my site with it. After a frantic couple of hours (midnight to 2 AM Swedish time) I’m back up and running in a shiny new data centre in USA-Southwest.
The site is now running again at www.cloudcasts.net, but due to the change in the Azure app name, links to cloudtv.cloudapp.net are broken. At the moment I am seeing a big drop off in traffic, so I’m guessing there are a lot of links to the old URLs. If you have linked to the site using cloudtv.cloudapp.net, it would be great if you can update it.
As the old saying goes, developers make the worst administrators.
by community-syndication | Nov 10, 2009 | BizTalk Community Blogs via Syndication
I’m not surprised at all about this announcement from Doug Purdy about the changes coming to the “Oslo” tools. Ever since the Connected Systems group was “merged” with the data group, it seemed a foregone conclusion that the modeling work would begin to heavily focus on the Microsoft data stack. I’ll wait to see how the tools evolve before making an opinion about their usefulness. I’m actually optimistic that in the end, more Microsoft developers will be better off as the tools will be more likely to help them in their everyday development. As it was, the M language and associated tools seemed to be targeting a niche market of language developers. Looking forward to PDC and hearing all about how these new tools are going to help me model my application data and hopefully help build up a good deal of the infrastructure for my data access layer.
by Richard | Nov 10, 2009 | BizTalk Community Blogs via Syndication
I like to divide BizTalk based integrations into three different patterns.
-
Point-to-point integration
-
Broker-based integration
-
ESB-based integration
I am sure someone could come up with fancier names but I will in this post try and dig into each of them, explain what I mean by them. I will also try and highlight some issues with each of the patterns.
Point-to-point integration
This is where a lot of us started. The idea is that the sending system has information and knowledge about the receiving system.
This usually means that the messages are exported in a message format that is tailored to the format of the particular receiving system’s needs. It also means that we usually get one integration process for each receiving system there is.
The example in the figure on the right shows a sending system that sends information about invoices to two different receiving systems (“System A” and “System B”). Using a point-to-point pattern in this scenario we end up with two different types of messages that are exported. Each of the exported messages that are suited and tailored to the format of the receiving system.
Issues
The main problem with this kind of point-to-point integration, where the sending system has detailed knowledge about the receiving systems, is that this knowledge translates into a coupling between the systems. When we tie the export message format from the sending system to the format of the receiving, all changes in the receiving system will also cause changes in the sending system.
Suppose there is a sudden need to change the format of the receiving system – as we use that format as our export format we now also have to change it there.
Another problem is the lack of agility. In this invoice scenario all other system that also has the need of invoice based information has to get this by going all the way back to the sending system and develop a whole new specific integration – separate to the existing ones.
Broker-based integration
In the broker-based scenario the integration platform is used as a broker of messages.
This means that only one canonical format is exported from the sending system. The broker then handles the routing to the different systems and the transformation to the message formats that the receiving systems expects.
The main advantage between this approach – where the sending system do not know anything about the receiving systems – and the point-to-point pattern is agility.
If there now is a need for invoice information in a third, new system, we do not have to change the export from the sending system (as long as we have all the information need that is) or develop a whole new integration. All we have to do is to route the invoices so that they also are sent to the third system and transformed into the format that the system expects. A new BizTalk map and port and we are done!
Issues
In my point of view this approach to integration has a lot of advantages over the point-to-point integrations previously discussed. And in a lot of simpler, stabile scenarios it works just fine and is the way to go.
But in some scenarios it kind of breaks down and becomes hard to work with. The problems is related to configuration and how we define the routing information in BizTalk. In BizTalk we can either create an orchestration and “hardcode” the process that defines which systems the messages should be sent to. We can also create a “messaging” scenario where we configure this routing information in the different BizTalk port artifacts by setting up filters.
Regardless if we choose a “messaging” or orchestration based solution the routing information becomes hard to update as the solution grow in size. We either get very complicated orchestrations or loads of ports to maintain.
Furthermore the whole process is very coupled to the one canonical schema which makes versioning and updates hard. If the canonical schema needs to be updated and we still need to be able to send information using the old schema (so we have a “version 1” and “version 2” of the schema side-by-side) all artifacts needs to be more or less duplicated and the complexity of the solutions grows fast.
This makes business agility hard and any changes takes long time to develop and deploy correctly.
I guess these issues has more to do with how BizTalk works than the integration pattern itself – but this is a BizTalk blog!
ESB-based integration
ESB-based integration in BizTalk is today achieved using ESB Toolkit from Microsoft.
One of the ideas of ESB-based integration is that the integration platform should not have hardcoded routing information. These routing rules should either be looked up at run time or travel with the actual payload of the message (called “dynamic routing”).
This in combination with having generic on- and off-ramps instead of loads of separate ports to maintain promises to create more agile and configurable solutions (called “Loosely coupled service composition” and “Endpoint run-time discovery and virtualization”).
The figure again shows the invoice scenario used previously. In this case we export a “Invoice 1.0”-format from the sending system. The format is not directly bound to a schema in the port (as we are used to in BizTalk) but it is basically possible to send any message format to the on-ramp.
The on-ramp then identifies what kind of message it received (for example using the XML-namespace) and looks up the routing rules for that specific message (the message “itinerary”) in a repository.
In this scenario there could be rules to route the message to a orchestration or directly to a send port. _All the configuration for this port is however configured as part of the itinerary and applied at run-time on the generic off-ramp port. And as itineraries are simple XML documents they are super light to update and deploy in the repository! _
So if we now wanted to update the “Invoice”-format to “version 2.0” all we would have to do is to create a new XML itinerary for the “Invoice 2.0” message type and possibly create new orchestration to handle the new message type. No new ports, no new bindings etc, etc. The configuration and deployment would be a lot simpler than before! We would end up with a lot fewer artifacts to maintain.
And the itinerary for “Invoice 1.0” would still be applied to all incoming Invoice 1.0 messages. Thus we have achieved what used to be so hard with a lot less development power!
Issues
With agility and dynamic capabilities comes complexity in debugging when something bad happens … I also feel that we give up a lot of validating and control capabilities that we had in the more schema-coupled patterns previously discussed.
I am new to this ESB-based model and I would love to hear your experiences, problems, stories etc!
I am however sure that this is the way to go and I would not be surprised if ESB like patterns will play an ever bigger role in future BizTalk versions!
by community-syndication | Nov 10, 2009 | BizTalk Community Blogs via Syndication
SQL Server Management Studio now has support for SQL Azure. The download is now available on MSDN at
http://blogs.msdn.com/ssds/archive/2009/11/10/9920168.aspx
by community-syndication | Nov 9, 2009 | BizTalk Community Blogs via Syndication
Today I am presenting a common mistake that several folks have committed when using our latest .NET 4 bits. This user experience has its origin in the simplified configuration work developed in this upcoming version of the framework. I will summarize it with the following scenario.
Suppose you would like to write a new WCF Workflow Service Application using Visual Studio 2010. The configuration file that is added to your WF service when using this Visual Studio template makes use of the simplified configuration features in .NET 4, and thus it does not specify any <services> section to define endpoints for your WF service:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
Therefore, a set of default endpoints will be added to your service.
Now, imagine you would like to take advantage of the new WS-Discovery features and so make your WF service discoverable at runtime. In order to do that, you will need to add a ServiceDiscoveryBehavior and a DiscoveryEndpoint to your WF service. Since the most natural way to do this is via service configuration, you may want to expand the previous configuration to:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service name="Service" behaviorConfiguration="ServiceBehaviors">
<endpoint name="Endpoint"
address=""
binding="basicHttpBinding"
contract="IService" />
<endpoint kind="udpDiscoveryEndpoint" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehaviors">
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
<serviceDiscovery />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
This service configuration look probably reminds you of what you previously had to write to develop your web services in .NET 3.5 using WCF.
In order to make sure your service is ready to be deployed, you can press CTRL-F5, and then select Service1.xamlx. The following unexpected screen appears:
Why is the metadata publishing currently disabled? Looking at the configuration file, the service we just opened seems to have a ServiceMetadataBehavior with the httpGetEnabled property set to true. Why is this not working properly then?
If you take a closer look at the configuration file, you may realize about the following: the default service name in the WCF Workflow Service Application template is Service1, and not Service. After changing the service name in the configuration file to be Service1, and pressing CTRL-F5 again, you will now be able to see the following:
The correct configuration has been added to your service!
What we have experienced here is the result of mistyping your service configuration name. When the service was opened, since no explicit configuration was found for it, a default set of endpoints with no default service behaviors was added to your service, and that is why the metadata publishing was not being enabled.
In .NET 3.5, the user experience was an InvalidOperationException thrown when a service was to be open to indicate that it “has zero application (non-infrastructure) endpoints. This might be because no configuration file was found for your application, or because no service element matching the service name could be found in the configuration file, or because no endpoints were defined in the service element.” However, due to the simplified service configuration work in .NET 4, this will not be the case in the upcoming version of the framework, and users will need to make sure that the proper configuration (e.g., security, encoding, etc.) is correctly added to their services.
We are currently thinking on different ways to mitigate this. Adding design time configuration validation seems to be the best solution so far. Opinions?
by community-syndication | Nov 9, 2009 | BizTalk Community Blogs via Syndication
|
I’ll be there. I’m happy about it. The sessions looks promising, although I have to say that the functionality of the website as far as scheduling goes really blows. There it no way to visualize your schedule, and no way to export it to your outlook calendar or even to something like Excel. That I’ve found to this date.
|
|
There are three sessions awarded with the BizTalk keyword (listed in my order or interest):
Microsoft BizTalk Server Futures and Roadmap
Learn how BizTalk Server 2009 lets you focus on writing the code to do the hardcore business logic and let BizTalk take care of moving the data. Hear how your development skills with Windows Communication Foundation (WCF), and Windows Workflow Foundation (WF) work seamlessly with the powerful integration platform of BizTalk. Find out how BizTalk aligns with the Microsoft application server in the longer term.
Queuing and Publish/Subscribe in a Heterogeneous Environment
Queuing and publish/subscribe are common patterns for building loosely-coupled, distributed applications. Learn how to use Microsoft Windows Communication Foundation (WCF) the new Microsoft ASP.NET 4.0 routing service, the Microsoft .NET Service Bus, and Microsoft BizTalk Server to easily connect heterogeneous systems. We then introduce AMQP (the Advanced Message Queuing Protocol), an important new open standard for interoperable message-oriented middleware, which will reduce the friction in connecting heterogeneous clients. A real-world scenario shows AMQP in action, connecting WCF, Microsoft Excel, and Java-based clients.
Connecting Applications with the Microsoft BizTalk Enterprise Service Bus
See how the BizTalk Enterprise Service Bus (ESB) enables you to build services that can be quickly located and connected, whether they live behind the firewall or in the cloud, without creating a brittle point-to-point link. Learn how to dramatically improve the service lifecycle of development, testing, and deployment by using the powerful messaging, routing, and transformation capabilities of the BizTalk ESB in your solution today, and get a glimpse of future plans for BizTalk service bus/pub-sub pattern
by community-syndication | Nov 9, 2009 | BizTalk Community Blogs via Syndication
Thought this may be of interest to some SBUG Members as they will be discussing SQL Server 2008 R2 and SQL Azure at the Edge UG
http://edgeug.net/
by community-syndication | Nov 9, 2009 | BizTalk Community Blogs via Syndication
In a recent case the customer was attempting to install BizTalk 09 with SQL 2008 R2. It fails with the following error.
“Failed to create Management database ‘BizTalkMgmtDB’ on server ‘XXXXX’. Error ‘0x80040E1d’ occurred.”
The server name is represented by the “XXXXX”.
No follow up has been done to explain the problem. The BizTalk 09 product site does not mention support for this version of SQL.
Building Projects with BizTalk 09
Beware when building projects with BizTalk 09. There is a problem with references. There are various manifestations of the problem. Artifacts from referenced projects may not be available. Messages types requiring a reference to another project may not be available. Maps requiring schemas from referenced types are not available. The hot fix is under development and should be available in the near future. This could be a bigger problem as more symptoms are discovered. One fix may not fit all.
