BizTalk deployment – How do YOU do it?

by | Dec 18, 2012 | BizTalk Community Blogs via Syndication


For the deployment of BizTalk applications we use a custom made tool within my company Cnext. Now I was curious to have some feedback from the community on the deployment of BizTalk applications. How do you handle the biztalk deployments at your company?
Our deployment manager tool is based on the idea to store all used objects in a database model (BizTalk artifacts, but also stuff like MSMQ, file locations, SQL objects, etc. ). Most of these objects are added using auto discovery of the BizTalk databases, so manually adding of objects is reduced to a minimum. Above all, BizTalk artifacts can have a different configuration (binding) defined per environment (test, dev, prod, ).
It also allows you to define all dependencies. Again most of these dependencies will be defined by the tool automatically.
This way of working makes it possible for the tool to define which actions need to be taken to deploy a certain application (or just a part of the application or only some objects). The deployment manager tool will defin which objects need to be removed and redeploy (also unenlisting/disabling en starting/enabling artifacts will be done by itself). As a result, using the tool will allow us to deploy much faster, because the objects to redeploy is reduced to an absolute minimum and now complete redeploy is needed (like BizTalk Deployment framework does for example).
Another very useful and much used functionality is the possibility to define complete business/functional flows, including some generic components. This makes sure you can also deploy or redeploy a complete (new) flow (like an order flow for example) by itself, including all necessary objects (as well receive as send ports, file locations, etc. ).
The deployment can be done cross BizTalk application. So the separation in applications is no longer deployment dependent.
The most important part is to set the database model correct en keep it this way this will guarantee a much easier and faster deployment, where each environment has its own version of the current deployed objects.
Please answer following questions:
  1.      Is your BizTalk deployment automated (BizTalk deployment framework, custom scripting with MSBuild or BTSTask, powershell scripts, etc. ), or do you just do manual deployment using MSI and binding files?
  2.        Which deployment tools or scripts are you using, or have you used before? And what are your thoughts of these tools (benefits and complaints)?
  3.        What do you think of a tool like our custom deployment manager tool (using autodiscovery, etc. )?

Thanks for your replies.
 When there is enough feedback, I’ll devote a new post on my analysis.

White Paper: Supportability and operations of Microsoft BizTalk Server

by | Dec 18, 2012 | BizTalk Community Blogs via Syndication

My first white paper on BizTalk Server has been published through my company motion10. The title is Supportability and operations of BizTalk Server. It can be downloaded through this link.

The white paper will discuss supportability of BizTalk Server. Something you should be thinking of when setting up a BizTalk environment or when your current environment lacks or needs improvement in that aspect.

Thinking about supportability of BizTalk from the very beginning should be one of the best practices that organizations need to implement. Because the team responsible for supporting the BizTalk Server environment is not involved at the beginning, during the deployment of the environment or are pulled into a project at the very end, in many projects the supportability is overlooked or not part of the initial project plan. This will lead to increasing costs of supporting the BizTalk environment as the administrators are ill prepared, poorly trained or may lack the necessary skills, and even worse given a poorly performing, not well designed and/or unhealthy BizTalk environment to support.  
This white paper will provide you with a process you can follow up, the necessary set of tools and guidance to implement a sustainable and robust BizTalk environment that can be efficiently supported by your technical staff. 

To write this paper I used my experience in the field and received valuable input from people that helped me with this paper. Many thanks go to the following people for their time, input and reviewing this paper in their precious (spare) time; colleagues Marnix Cox, Andre Ruiter and Sander Nefs, fellow Microsoft Integration MVPs Gijs in ’t Veld, Sandro Perreira, Nino Crudele, Saravana Kumar and Kent Weare, and dedicated BizTalk community members Tord G. Nordahl and Hendrik Roth.

I hope you enjoy reading this paper. Any comments or suggestions are welcome and can be sent to SteefJan@msndotcom

Cheers,

Steef-Jan

BAMAlerts – The activation state cache could not be updated.

BAMAlerts – The activation state cache could not be updated.

by | Dec 17, 2012 | BizTalk Community Blogs via Syndication

If you have log shipped or detached/attached the BAMAlerts databases, you will have issues starting the notification service on the BizTalk server for BAM alerts. The reason for this, when these databases are restored, the the ‘Cross-Database Ownership Chaining’ option on the BAMAlertsApplication and BAMAlertsNSMain databases is disabled and greyed out. Greyed out because it […]
Blog Post by: DipeshA

Performance Point – the Good and the Bad – Part 1

by | Dec 16, 2012 | BizTalk Community Blogs via Syndication

This posting presumes the reader has at least a basic understanding of what Microsoft’s Performance Point (PP) offering is, at least at the level of wanting to assess whether it is appropriate for your requirements. Basic familiarity with Microsoft’s Analysis Services is also required to get the most out of the observations I provide. If […]
Blog Post by: Mark Frawley

Configure the Exception Management Framework in the ESB toolkit to route fault messages to SQL Azure

by | Dec 14, 2012 | BizTalk Community Blogs via Syndication

The ESB Exception Management Framework provides the ESB Exception Off-ramp that subscribes to all ESB-generated fault messages, but also to exceptions generated by the BizTalk Server failed message routing mechanism. The component routes fault messages to the ESB exception management database, but is it also possible to configure it to route to SQL Azure?
The Exception Management Framework in BizTalk 2013 still uses the SQL adapter to send messages to the EsbExceptionDb database. The SQL adapter runs distributed transactions and uses the Data Transaction Coordinator (DTC). In Azure you can’t use DTC so let’s see what we have to modify to make it work.

 

Steps

The following tasks must be performed to route fault messages to SQL Azure :

  • Create a new SQL Azure Database
  • Copy the necessary tables and procedures from the ESB exception management database to the SQL Azure database
  • Create a new map in Visual Studio to map to the stored procedure in the SQL Azure database
  • Modify the ESB Exception Off-ramp in BizTalk to use the WCF-SQL adapter and the new map.
 
Create a new SQL Azure Database
Open the Windows Azure Management Portal in the browser.
Location: https://manage.windowsazure.com/
 
To create a database, click SQL DATABASES in the left-hand navigation pane and click on CREATE A SQL DATABASE.
 
Enter Login Name, Password and the location of the Data Center.
 
Enter Database Name, Maximum Database Size, Collation and the name of the Subscription.
 
 
Copy the necessary tables and procedures to the SQL Azure database
In SQL Server Management Studio, connect to the EsbExceptionDb database from BizTalk.
 
Right-click on the Fault table and script the CREATE TABLE statement to a File or a New Query Editor Window.
 
Also script the stored procedure: usp_insert_Fault.
 
Note
The Exception Management Framework also uses other tables and stored procedures but in this example we are only using the main table. *(See Conclusion)
 
In SQL Server Management Studio connect to the newly created SQL Azure database.
 
Open a New Query Window and use the generated scripts to create the Fault table and the usp_insert_Fault stored procedure on the SQL Azure database.
 
Note
Not all keywords are supported in SQL Azure. Remove the ON [PRIMARY] keywords from the CREATE TABLE statement otherwise you will get an error like:
‘Filegroup reference and partitioning scheme’ is not supported in this version of SQL Server.
 
 
Create a new map in Visual Studio to map to the stored procedure in the SQL Azure database
The map in the ESBFaultProcessor pipeline in the ESB Exception Off-ramp is for the SQL adapter so you have to create a new map for the WCF-SQL adapter.
 
In Visual Studio create a new BizTalk project
 
To create a .XSD schema for the usp_insert_Fault stored procedure:
In the Solution Explorer right-click the BizTalk project and add a generated item. Choose: Consume Adapter Service.
 
Connect to the SQL Azure database and select the usp_insert_Fault stored procedure. Click on OK.
 
The ESBFaultProcessor pipeline in the ESB Exception Off-ramp creates a FaultMessage. The FaultMessage schema is located in the Microsoft.Practices.ESB.ExceptionHandling.Schemas.Reporting.dll library. Create a reference to the library to use the schema.
 
Create a new map and connect the FaultMessage schema to the usp_insert_Fault schema.
 
Note

I’ve got the following exception when I close the map in Visual Studio 2012. A Beta bug?!

Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
Stack:
at Microsoft.BizTalk.Mapper.MapperVsPackage.ConnecterShape.ConnecterPosition(System.Windows.Forms.TreeNode, Microsoft.BizTalk.Drawing.DrawingControl, Int32, Int32)

 
 
Modify the ESB Exception Off-ramp in BizTalk to use the WCF-SQL adapter and the new map.
Deploy the BizTalk project with the created usp_insert_Fault schema and map to the Microsoft.Practices.ESB application.
 
Go to the ALL.Exceptions Send Port in the Microsoft.Practices.ESB application. Right-click the send port and choose: Properties…
 
Change the transport Type to WCF-SQL and click on Configure..
 
Change the URI to the SQL Azure database and set the Action.
In the binding page set UseAmbientTransaction = false.
On the Credentials tab set the username and Password.
Click on OK.
 
In the Send Pipeline properties set the new map
Also disable the ESB BAM tracker *(see Conclusion)
Click on OK.
 
Now the ESB Exception Off-ramp is configured to send messages to SQL Azure!
 

 

Test

Enable routing of failed messages on the Send Ports in a BizTalk application to capture BizTalk errors.

View the BizTalk errors in the SQL Server Management Studio
 

 

Conclusion

It is possible to modify the ESB Exception Off-ramp and send error messages from BizTalk to SQL Azure. However in this example I’m only using the main Fault table. I didn’t try it with multiple tables but it should also be possible. Furthermore I disabled BAM in the ESB Exception Off-ramp. That’s also a nice challenge to get it working.
In the next post I will try to create a portal or a website so that a user can view the faults without de need of SQL Server Management Studio.

You can download the sample schema and map here: http://www.ithero.nl/downloads/itHero.ESB.ExceptionHandling.zip
 
Stay tuned!!

(Message 4035) BACKUP LOG cannot be performed because there is no current database backup

(Message 4035) BACKUP LOG cannot be performed because there is no current database backup

by | Dec 14, 2012 | BizTalk Community Blogs via Syndication

Hi everyone, last time I got a disk space issue, after purging some data and backup, I tried to run the biztalk jobs. But the DTA backup job failed with this error Executed as user: xxx. Processed 3233 pages for database ‘BizTalkDTADb’, file ‘BizTalkDTADb_log’ on file 1. [SQLSTATE 01000] (Message 4035) BACKUP LOG successfully processed […]
Blog Post by: Jeremy Ronk