Deploying websites/webservices in IIS 7.0

BizTalk has out of the box abilities to expose itself as a web service (exposing as a schema / orchestration) or consume custom web services. The web service wizard is an easy way to setup the web services during development but what if you would like to deploy the web service.

The most obvious way would be to add the virtual directory as a resource to the BizTalk application (for more info follow this link). This way the website will be part of the MSI and will be deployed together with the BizTalk artifacts. An alternative solution would be to use MSDeploy to deploy your web services. MSDeploy is part of the Web Deployment Tool and enables you to package an existing website (including content, configuration, certificates and databases). MSDeploy contains both a command-line interface as a GUI.

Command-line interface example

To package a website the following command should be executed:

Msdeploy.exe –verb:sync –source: iisApp=”Default Web Site\My Sample WebService” –dest:package=”M:\Projects\”

To import the package on the web server the following command should be executed:

Msdeploy.exe –verb:sync –source:package=”M:\Projects\” –dest:iisApp=”Default Web Site\My Sample WebService”

GUI interface example

After installation of the Web Deployment Tool a new menu item is available in IIS. Right click the web site/virtual directory that you want to deploy and go to “Manage Packages”.


Select “Export Application” to package the web site/virtual directory to a zip file.

To import a package on a web server select “Import Application“.

Source (MsDeploy.Application) and destination (iisApp) are not compatible for given operation

In the RC version of the Web Deployment Tool this error can occur when a package that is exported through the GUI is imported back through the command-line interface. A work-around for this issue is not to mix the command-line interface with the gui interface. If you exported through the GUI then import the package through the GUI also.

BizTalk Security – Adding permissions to the BizTalk Operator role

Every BizTalk administrator has probably already received complaints from BizTalk operators that operators can see the number of suspended messages but can’t view the message itself. Another common remark might be that the operators cannot use the Orchestration debugger. Debugging in production is not advised but with the debugger you can at least verify where the orchestration has halted.

Off course, for organisations where IT operations needs to comply with security regulations like Sarbanes Oxley or other compliance rules, the Microsoft best practices for BizTalk security apply. These can be found here. When these compliance rules do not apply for your organisation and after checking with the security responsible you can tackle these problems.

The super operator

There is a way to make it possible for operators to view and save messages with the administration console and let them use the orchestration debugger. Most of the BizTalk security resides in SQL server. In the form of two roles: BTS_OPERATOR for the Operators and BTS_ADMIN_USERS for the BizTalk Administrators. These roles are defined at database level. They can be found in every BizTalk database.

When configuring the BizTalk group these roles are created for operators and administrators with the relevant permissions (securables) on database objects. The Windows groups specified for operators and administrators in the BizTalk group configuration are given a SQL login and granted the accompanying role.Each role has its own securables. These securables are permissions on objects such as stored procedures and tables.

The BizTalk Administrators have a lot more of these securables. Here under you will find the steps to creating a super operator role that delivers extra permissions to operators, for example the permission to save messages.

1. Create a windows group for the super operator.

First we need to create a windows local group, if you do not use active directory accounts and groups, or an active directory group.
Add the members who deserved the super operator rights. These members must already be member of the operator windows group.
This because the super operator group is only an extension to the operator permissions.

2. Create the SQL login for the super operators.

  • Open the SQL management studio and connect to the SQL server that is hosting the BizTalk group databases.
  • Open the server security tab and create a new login by right clicking login and selecting new login.
  • In the login textbox you specify the group you created in step 1.
  • On the user mapping tab you check the checkbox for every BizTalk database.

In this way a user is created for the group in every BizTalk database.

3. Create the super operator role.

A role must be created for the super operator in the necessary biztalk databases. In this scenario we only need to create a role in the BizTalkManagementDB and the BizTalkMessageBoxDB.
For other scenarios it might be possible to create such a role in the BAM databases too.

  • In the SQL management studio expand the Messagebox Database and right click on the roles node.
  • Select new database role.
  • Name this role BTS_SUPEROPERATOR. The owner can be DBO.
  • Add the group you created in step 1 to the role members.
  • Do the same in the BizTalkManagement database.

4. Adding the securables for saving/viewing messages permissions.

In the messagebox database doubleclick the super operator role. Open the tab securables and add the securables according to the screenshot following these steps:

  • Click add.
  • Select specific objects, click ok.
  • In object types check the stored procedures checkbox, click ok.
  • Click the browse button and put a check next to the stored procedures you see in the screenshot.
  • Select every securable one by one and grant the role the execute right.

Now you need to add the securables to the role in the management database.
Follow the steps above but this time add the securables seen in the next screenshot.

That’s it. With the new super operator group created we have an extra level of security. This can be really handy because there are only two roles out of the box. Now there are regular BizTalk operators, BizTalk super operators with save permissions and the BizTalk administrators.

5. Adding another permission, the Orchestration debugger.

To give the newly created BizTalk super operators this additional permission you just have to add some extra securables to the SQL super operator role. Add these securables to the super operator role in the BizTalkDTADb, and grant the execute right to the role for each securable:

We will continue to search for extra permissions to add to the super operator role. These permissions will be posted soon. If you have also found out which securables accompany certain rights or if you have any questions about this topic, feel free to comment them on this post.

WCF-Oracle adapter for BizTalk 2009

This article will give a short and easy explanation on how to use the WCF-Oracle adapter to retrieve a result set from an Oracle database.

The first thing we need to have on the Oracle database is a stored procedure that returns an object of the type ref-cursor.
This article will give some examples on how to program them. The second thing we need to do is to install an oracle client.
This has to be done so we can add an oracle service that can connect to the database, this service will be used later on to retrieve the metadata.
Installing the client will also add the necessary oracle drivers. In this example we added the service Oracleblog with the right settings for our database.

Now we can start developing.
The first step of the development is to generate the metadata and the request-response schemas.
We start by creating a BizTalk project in Visual Studio. After having created the project, we right-click the project and choose “add generated item”. Now we choose “Consume Adapter Service” to start the wizard. This new wizard was added in Visual Studio by installing the WCF-Oracle adapter.

In the wizard we first choose OracleDBBinding for “Select a binding” then we click “configure” to configure the database settings. The first thing we do is adding the name of the service we created in the oracleclient in the field DataSourceName on the pane URI. After this we can add the required credentials. Now making the connection by clicking “connect” will show all the databases available. We have to find the right stored procedure and add this to your BizTalk project. In our example we added the stored procedure P_SEARCH.

Adding it to your project will give you two things:

The request-response schema
The binding file for your send port

In this example two schemas are generated, this is because one schema is referring to the other. Both request and response schemas are created in the same XSD-file. Now we can create a simple orchestration in which we make a mapping to the request schema and create a request-response port so we can send the request and receive the file with the record set.

Now we deploy the project to add the orchestration to the BizTalk server. The next thing we do is creating the proper send-receive port for sending to the oracle database. We do this by importing the binding file that was generated with the schemas in to our BizTalk application. This will create the send-receive port with the correct action- and database settings. We now make a file receive and send port and bind this to our orchestration.

We are now ready to send the message.