By sam
December 11, 2010 at 3:25 PM

Apparently, I was lucky to be in the first batch of beta participants for the 3 new Azure beta programs:

  • I received the confirmation for the extra small instances rather fast
  • Wednesday evening, I received confirmation for the Azure Connect beta program.  You can read my post on that here: Azure Connect: VPN as a Service, a quick introduction.
  • And later that night, I received confirmation for the VM Role beta program.

This post will demonstrate how to upload a virtual hard disk to the Azure storage and how to configure it to run it as your own instance(s) in the cloud.

Creating the VHD

Microsoft Hyper-V on server, or VMWare workstation on laptop?

I was very happy with Windows Virtual PC.  It was lightweight, free and pretty stable.  It allowed us, developers, to use it on our laptops on the road, at our customers, in the office.  But there is one important thing: Virtual PC does not support a 64-bit OS on a guest system.  And that became a big problem with the introduction of Windows Server 2008 R2; that operating system is only available in 64-bit, which makes sense. 

Because of this, we needed an alternative:

  • Hyper-V: free, stable, Microsoft-product, but not running on Windows 7
  • VMWare Workstation: not free, stable, non-Microsoft product, but running on Windows 7

So, I decided to use VMWare for the creation of my virtual machines for Azure. 

To leverage the full capabilities of the VM Roles, it would be better to use Hyper-V though, since that allows the usage of differencing disks, which would be a big timesaver for incremental updates to a virtual machine image.  But for now, I’ve used VMWare, since I didn’t have a physical Hyper-V server available.

Preparing the Virtual Machine

I took the following steps to create the Virtual machine.

  • Created a virtual machine
  • Installed Windows Server 2008 R2 Enterprise edition on it
  • I enabled the Application Server and Web Role (and therefore also the .NET Framework 3.5.1 features)
  • I installed all updates, but disabled the auto update feature.

Installing the Windows Azure Integration Components

  • The Windows Azure Integration Components are a set of components that are needed to be able to communicate with the Windows Azure Fabric controller.  They need to be installed on the virtual machine, prior to uploading the machine to the Azure storage.
  • Load the iso file that is found in the Azure SDK (iso directory - wavmroleic.iso) as a DVD/IDE in your virtual machine
  • Start the installer on the virtual machine, by double clicking WaIntegrationComponents-x64.msi
  • Follow the installation screen (Next-next-finish)

Please make sure that the firewall windows service is enabled (see ‘Things to know’ at the end of this post)

Sysprepping the Virtual machine

There are some specificities with VM Roles that are different from a typical hosting/IaaS solution.  I discussed some of these in my previous post: Hosting BizTalk Server on Azure VM Role.  One of the important things to know is that the machine name of the Virtual Machine is changed and assigned at runtime by the Azure Fabric controller.  This makes sense, since it is possible to configure multiple instances for a VM Role.

To make the virtual machine ready for these actions, the machine needs to be ‘sysprepped’.  This is a typical action that is taken when creating a base image for a machine.  It provides a different SID and name for the machine.

  • Run the %windir%\system32\sysprep\sysprep.exe tool
  • In the popup windows, select the “Enter System Out-of-Box experience (OOBE)” for the System Cleanup Action
  • Make sure that Generalize is selected and select Shutdown in the Shutdown options.
  • OK

vm0 sysprep

[Only with VMWare] : Convert to VHD file

  • This step is only needed when using VMWare. 
  • I used the tool VMDK to VHD Converter and that allowed me to convert my VMWare virtual disk to a VHD.

Uploading the Virtual Hard disk (VHD)

The VHD file now needs to be uploaded.  For this, the Azure SDK 1.3 comes with a command-line tool: CSUPLOAD.  Using this tool, we can upload the VHD to our Azure subscription.

  • Open the Azure SDK Command prompt
  • Type the following command to link the context to your current subscription:
    csupload Set-Connection “SubscriptionId=[SubscriptionId];CertificateThumbprint=[tp]”
    The subscription id can be found on the management portal in the property grid, when selecting a subscription.
    The certificate thumbprint needs to be a private certificate that is installed on the local machine and that is linked to the management certificates on the Azure portal.  On the Azure portal, you can easily copy the thumbprint from the property grid.
  • Now the upload command needs to be done
    csupload Add-VMImage –LiteralPath [localpathtovhd] –Location “West Europe” –Name [cloudname]
    Passing in the localpath to the VHD is important.  Next to that, the location (data center) needs to be defined where the page blob will be created.  And optionally you can specify a friendly name that will be used on the Azure management portal.
    vm1_commandline
  • When this is done, a verification window pops up.  This indicates that the image will be mounted to verify some settings (like Operating System, etc).  This verification is important because it can prevent you from uploading a VHD of several GBs, and then finding out there is an incorrect configuration.
    If the operating system you’re uploading the VHD from does not support mounting a VHD, you can use the parameter –SkipVerify of the CSUpload tool to skip this step.
    vm2_verification
  • After the verification, the upload to the Azure data center starts and that seems to be a good moment to have a sleep (like I did), take a break, or do something else.  The upload typically will take some hours and therefore, the csupload tool is recoverable from connection errors.
    vm3_inprogress
  • As soon as the upload process starts, you can already look at the Azure portal and see the status of the VHD as pending.  The VHD is created as a page blob.
    uploadportal
  • After the upload is completed, you can see the status of the VHD to committed on the Azure portal.  When the connection breaks, it is possible to re-execute the command and the upload will resume where it stopped.  (see ‘Things to know’)

Configure the Azure Role Service

Create Visual Studio Project

  • In Visual Studio (after installing the Azure SDK 1.3 and the VMRole Beta unlocker), you can create a new Visual Studio Cloud project and add a VMRole to the Cloud project.
  • On the property page of the VMRole project, you can specify the credentials and the VHD that is uploaded to the Azure platform.
    vm4_prop1
  • On the Configuration tab page, you can specify the number of instances and the size of the instances (notice that I can use the Extra small instance size here, part of the beta program)
    vm4_prop2
  • It is also required to open the endpoints when needed (like when IIS needs to be used, you’ll typically create an HTTP endpoint on port 80 or 443)

Publishing the project to Azure

  • Now it is straightforward to publish this project to Azure, using Visual Studio, or by uploading it on the Azure management portal.
  • After the upload is done, you can see on the management portal the process of the Virtual machine.
  • The roles take the following statuses
    • Initializing
    • Waiting for host
    • Setting up Windows for first use
    • Starting Windows
    • Starting Traffic
    • Ready

portal_status1
portal_status2
portal_status3
portal_status4
portal_status5

Things to know & troubleshooting

Don’t disable the Windows Firewall service

On my virtual machine (locally), I had disabled the Windows Firewall service.  Because of that, the installation of the Windows Azure Integration Components failed with the following exception (copying it here for bing/google search):
Product: Windows Azure VM Role Integration Components -- Error 1720. There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action InstallScriptAction script error -2147023143, : Line 81, Column 5,

After I enabled the Windows firewall service again, things worked smooth again.

Resuming the upload

  • Just before the upload finished, I received a timeout exception on the csupload command.  So, I decided to find out if the resumability of the CSUpload tool works as announced.
  • I re-executed the command the 1st time and I noticed the upload started again at 3,2%…  Knowing that I’ve seen the upload pending at 98%, the last time I checked, I decided to retry it again.  (ctrl+c to exit the command)
  • The second time, the resume started at 87,3%.  So I tried again.
  • And, third time lucky!, now I immediately received a confirmation of the upload.  And the management portal also reflected this well.

Don’t install the Windows Azure SDK on the Virtual Machine

It is not supported to install the Windows Azure SDK inside a VM intended for use with VM role. The Windows Azure SDK and the Integration Components are mutually exclusive.

No support for startup tasks

Unfortunately there seems to be no support to use Startup tasks in VMRoles.  So startup tasks will have to be ‘embedded’ in the Virtual Machine startup process.  This might change after the beta, off course.

Conclusion

Again, just as with the Azure Connect, I was very surprised by the simplicity of the process of getting things to work.  Off course, it takes more time, because of the preparation and the upload, but besides that, things looks solid and stable.

Things that I hope to see soon:

  • Base images on Azure that can be downloaded, so that only the differencing disks need to be uploaded.  This would save a lot of time and bandwidth.  (download is cheaper/faster than upload)
  • Start up tasks.

Great stuff.

Sam Vanhoutte, Codit

Posted in: Azure

Tags:


By sam
December 9, 2010 at 1:07 AM

I just received a notification that my request to join the Beta Program for Azure Connect was approved.  And that immediately got me starting to test it out.  Things look very straightforward.

I am using the phrase VPN as a Service for this feature, since it really explains it all.

Virtual Network Configuration of Windows Azure Role

Portal settings

  • After logging in on the Azure Portal, you can click the Virtual Network button in the left corner at the bottom of the screen:
  • After this, it is possible to enable the Virtual Network features for a specific subscription
  • When selecting a subscription, you can get the Activation Token from the portal, by clicking the ‘Get Activation Token’ button.  That allows to copy the activation token to the clipboard for later use.
    activationtoken

Visual Studio project settings

  • In Visual Studio, when having the SDK 1.3 installed, it is possible to copy the activation token to the properties of an Azure role in the property pages:
    vsproperty
  • Now you can deploy the role to the Windows Azure portal.

Adding an ‘on-premise’ server to the Virtual Cloud Network

Installing the Azure Connect Client software agent

  • On the local servers, it is now possible to install the ‘Local endpoint’, by clicking the correct button.
  • This shows a link to download the software on the machine (on premise).  This link is only active for a while.
    installclient
  • The installation package is very easy to install, by selecting the correct language and clicking Next-Next-Finish.  After the endpoint software is installed, be sure to open the TCP 443 outbound port.
  • As expected, the local endpoint agent runs as a Windows Service:
    service

Adding a local endpoint to an Azure Endpoint group

  • An Azure Endpoint group can be created, by clicking the “Create Group” button in the ribbon of the management portal.
  • This pops up a wizard where you can provide a name for the group and where you can add the local endpoints and Azure roles that should be part of the group.  You can also indicate if the local endpoints are “interconnected” or not.  This specifies if the endpoints can reach each other. 
    (be careful: in some multi-tenant situations, this can be seen as a risk!)
  • I could immediately see my local computer name in the Local Endpoint list and in the Role list, I could only see the role that was configured with the activation token for this Connect group. 
    image
  • That’s the only required actions we need to take and now we have IP/Network connectivity between my local machine and my Azure role in the Cloud.

Testing the connectivity

Since I had added the Remote Desktop Connectivity support to my Azure role (see my previous blog post: Exploring the new Azure property pages in Visual Studio), I am now able to connect to my Role instance in the cloud and connect to it.

  • After logging in on my machine, I was immediately able to connect to my local machine, using my machine name.  I had a directory shared on my local machine and I was able to connect to it.
    rdptest
  • For a nice test, I added a nice ‘cloud picture’ on my local share and selected it to be my desktop background in the cloud.  (the picture was on top of a Mountain in the French Alps, with the Mount Blanc in the background, for those wondering) 
  • A part of my cloud desktop is here:
    rdpdesktop

Conclusion

This was a very simple post, highlighting the way to set up the configuration between a Cloud app and local machines.  It really only took me about 5 minutes to get this thing working, knowing that I had never seen or tested this functionality before (only heard about it).

Some nice scenarios can now be implemented:

  • Making your Azure roles part of your Active Directory
  • Network connectivity between Cloud and Local (including other protocols, like UDP)

Definitely more to follow soon.

Sam Vanhoutte, Codit

Posted in: Azure

Tags:


By sam
November 29, 2010 at 10:10 PM

Great news for the Azure community.  The Windows Azure SDK and Windows Azure Tools for Microsoft Visual Studio (November 2010) have been released!  This release contains a lot of new features and most of them were announced at PDC.

The release can be downloaded here.

The overview of new features:

  • Virtual Machine (VM) Role (Beta):Allows you to create a custom VHD image using Windows Server 2008 R2 and host it in the cloud.
  • Remote Desktop Access: Enables connecting to individual service instances using a Remote Desktop client.
  • Full IIS Support in a Web role: Enables hosting Windows Azure web roles in a IIS hosting environment.
  • Elevated Privileges: Enables performing tasks with elevated privileges within a service instance.
  • Virtual Network (CTP): Enables support for Windows Azure Connect, which provides IP-level connectivity between on-premises and Windows Azure resources.
  • Diagnostics: Enhancements to Windows Azure Diagnostics enable collection of diagnostics data in more error conditions.
  • Networking Enhancements: Enables roles to restrict inter-role traffic, fixed ports on InputEndpoints.
  • Performance Improvement: Significant performance improvement local machine deployment.

This blog shows a first highlight of the new features that are part of the new SDK.

Extra small instance size

One of the nice features that many people have been asking for is the introduction of a new, lightweight, VM size: the Extra small instance.  They come with a small amount of memory (786 MB) and a low CPU speed (1Ghz), but at a very low cost (5ct / compute hour).  Configuring this is very easy, through the Role Configuration tab.

image

Remote desktop features

It is now possible to connect to an Azure instance, by using a Remote Desktop Connection.  The publishing wizard has been updated to enable this easily.  When deploying an application, you can provide a user name and a password for a remote desktop user, together with a certificate that has to be uploaded to the Azure portal, after exporting it with the private key.  (Export certificate - Browse to the portal – Your project – Installed Certificates – Manage – Upload certificate)

image

In the new Azure management portal, it is now possible to connect to a specific instance of an Azure Role, by clicking on the Connect button.

Public ports in endpoints

In previous SDK’s, it was unknown until at runtime at what actual port the role endpoints were hosted.  This can now be fixed and configured in the endpoints tab page on an Azure role:

image

Using Azure Connect

The Azure Connect feature is a very interesting feature that allows to set up a virtual network between Azure roles and the local network.  The property page of the Azure role allows to configure the specific token that is need for the Azure Connect feature.  This feature will be opened for a beta program soon, so we will be able to blog about it as soon as we are allowed in the beta program.

image

Sam Vanhoutte, Codit

Posted in: Azure

Tags:


By sam
November 25, 2010 at 7:24 PM

Another great announcement on PDC was the Virtual Machine Role feature.  This feature is added to Azure with the primary goal to move existing applications to the cloud. 

The feature allows us to upload our own VHD (virtual hard disk) with the Operating System on it (Windows 2008 R2 Enterprise).  This machine could have your application pre-packaged and installed.  After doing this, you are now able to spin up multiple instances of that machine.

BizTalk on VM Role?

Being a BizTalk Server architect that is highly interested in the Azure platform, I immediately thought about a scenario where I could have my own BizTalk Server in the cloud, on Azure.  But, knowing some of the limitations of the Azure platform, I knew I would have a lot of potential issues. 

I listed these issues and added the various workaround or solutions for it.  This post is a post, based on the PDC information and can contain incorrect information.  Consider it as some early thinking and considerations.

No MSDTC support with SQL Azure

  • Problem description
    • BizTalk Server relies heavily on SQL Server and uses MSDTC to keep transactional state across databases and with the adapters.
    • SQL Azure does not support distributed transactions and also introduces more latency to the database queries.
  • Solution
    • SQL Server will need to be installed on the VHD image locally
  • Consequences
    • It won’t be possible to build a multi-machine BizTalk Server Group through the VM role.

The OS image is not durable

  • Problem description
    • All changes that are being made after a Virtual Machine instance is started will be lost, once the instance shuts down or fails over.  (there is only one VHD, but multiple instances are possible –> concurrency issues)
    • This means all database state (configuration, tracking, process state) will be lost if an instance fails.
  • Consequences
    • It won’t be possible to have a stateful BizTalk Server configured or to host long running processes on a VM Role BizTalk Server
    • We will need to expose BizTalk Server capabilities as services to a stateful engine (Workflow?)

The Virtual Machine name will be assigned by the Windows Azure fabric controller

  • Problem description
    • Since it is possible to have multiple instances of a VM running, these instances will get a specific Computer Name assigned by the Azure Fabric controller. 
    • It is very hard to change the computer name of a BizTalk Server machine
  • Solution
    • We will need to automate the BizTalk Server configuration, using a Silent Install, once the VM is initiating.
  • Consequences
    • One of the biggest painpoints in setting up BizTalk Server in a VM role will be to configure the BizTalk Server instance on the fly as a startup task.
    • Starting / restarting a BizTalk VM Role instance will take a considerable amount of time

Licenses are needed

  • Problem description
    • BizTalk Server and SQL Server licenses are needed for each instance that is running
  • Solution
    • Since everything will be installed on a single box, we could use a standard edition of BizTalk & SQL
  • Consequences
    • There is no big pricing advantage, except for the operational cost
    • Only 5 applications will be supported , when using the standard edition

General conclusion

If we succeed in setting up BizTalk Server on VM Role at all, it will be a BizTalk Server with the following limitations:

  • No support for long running transactions
  • Single box machine
  • Stateless BizTalk box

Considering that integration as a service is on the roadmap of Microsoft (see session at PDC), we should only consider it as a temporary solution to have BizTalk Server configured on a VM Role.  If we do this, then we should just see it as a BizTalk Server that exposes its various ‘short running / isolated’ capabilities as a service.  (flat file parsing, transformation, pub/sub, connectivity, EDI)

Sam Vanhoutte, Codit


By sam
November 22, 2010 at 11:21 PM

Early Thinking

This post describes some new Azure features and how they might help us in leveraging the power of the web/app.config files again.  The content is this article is written, before any CTP/Beta versions of these features are available, so the details might be incorrect and there might be some wrong assumptions.  I will verify all of these parts, once the features are made available.

Current situation

Until now, an important difference between deploying a web application (or web service) on a local or hosted server and deploying a web application (or web service) to Windows Azure was the usage of the web.config file.

In a standard web application (hosted on IIS), the web.config can easily be changed to update configuration settings.  When changing this file, the web application gets refreshed and the new settings are being applied.

On Azure, there was a total different story.  The web.config was compiled with the deployment package and to change it, a new version of the packaged needed to be uploaded, resulting in a lot of work/time before the new settings got applied.  Luckily, Windows Azure provided a nice alternative: the serviceconfiguration files (.cscfg).  This file allowed to specify configuration values that could be loaded at runtime through the following code:

RoleEnvironment.GetConfigurationSettingValue("myValue"); code.

Painpoints with the Azure serviceconfiguration files.

The idea is great, having service configuration files managed on Role level and not on instance level.  But there are some big disadvantages in the following scenarios:

WCF Configuration settings

WCF has tons of configuration settings and I am a big fan of having my service endpoints configured through the .config files.  This allows for easy change and full declarative configuration, without having the settings (binding/behaviors…) compiled with the program.  And since the introduction of the WCF Router service, even more configuration (the pub/sub logic) gets in the .config file.

Having all these settings in the Azure .cscfg file, would be very hard to maintain, or we’d need to switch to custom configuration files.

Custom configuration settings

In most of the applications that are developed at Codit, we use custom configuration sections to have a better structured configuration experience.  These configuration sections are complex types and no standard name/value configuration pairs.  Migrating these applications to Azure, would mean our configuration logic would need to be totally redesigned.

ASP.NET settings

ASP.NET also include a lot of settings that might need to be changed at runtime.

PDC announcements

At PDC a lot of stuff was announced that can help us here.  This article described the various announcements and their impact on the configuration issues I described above.

Remote desktop capabilities

Through the updated Azure management portal (didn’t that look a 100 times nicer than the current one?), we will soon be able to have Remote Desktop access to our web.  This will be done by adding the following Modules in the service definition file (.csdef)

<Imports>

<Import moduleName="RemoteAccess" />

<Import moduleName="RemoteForwarder" />

</Imports>

This allows us to connect to a running instance of an Azure role.  This way we can alter the web.config file and have everything updated as on a regular web application.

The biggest disadvantages of this approach are the following:

  • When having multiple instances (which is required to have High Availability), we need to remote in on every running instance of our web role.
  • Our changes will be undone when our instance restarts or gets redeployed, because the machine gets ‘prepped’ again, resulting in a fresh installation of our Azure package.

The new Azure VM Role

Through the announced Windows Azure VM Role, we will be able to customize our own Virtual Machine, by uploading a pre-built virtual hard disk (VHD) to a blob storage account.

The steps to do this are the following :

    • Install Windows Server 2008 R2 Enterprise on the VHD
    • Add any Additional software you might need on the VM Role instances
    • Install Windows Azure Integration Components that include the following components
      • Agent
      • Runtime interface (topo, config, shutdown notification)
      • Remote Desktop configurator
      • Windows Azure Drives driver
    • Generalize the VHD is recommended, by using sysprep  (machine name will be assigned by Azure.)

By using a difference VHD, it might be easy to upload a new version of that VHD with the updated configuration file on it and have the changes applied.  Besides that, the same approach can be taken as described in the previous section (remote desktop capabilities).

The biggest disadvantages of this approach are the following:

  • To upload a new version of the VHD difference disk, the role might need to be reinitiated (to be tested, once the VM Role is available for CTP)
  • Cumbersome way of changing the web.config.

Startup tasks

As shown in the CloudCover show of two weeks ago (watch episode), there is a possibility of executing startup tasks, when the role instance starts up.  This looks like the best suited feature to solve our config file problem.

I am making one crucial assumption here (that I’ll check once this is made available):  I believe the start up tasks are being executed prior to the Role Instance initiation – so before the web application is started.  This means we can still change the web.config without having the web application being recycled automatically.

Leveraging the startup tasks will allow us to take the web.config from a configurable blob container and write it to the application directory on the Azure instances.  Therefore, we just need to write a script that performs this logic.  (code will be in a future post).  Then we just need to configure that script in the Startup element in the csdef configuration file:

<Startup>
     <Task commandline="updateconfig.cmd" executionContext="elevated" 
               taskType="simple/foreground/background"
/>
</Startup>

This approach looks like the best approach to make our web.config and app.config files configurable again.

Conclusion

A lot of uncertainties, because there is no bit available yet to test this with.  So, please expect a reviewed post, once it has been made available. 
But one thing is for sure: the new Azure features will make Azure application development much more flexible again.

Sam Vanhoutte, Codit

Posted in: Azure | WCF

Tags:


By sam
September 10, 2010 at 9:17 PM

I was building a test solution for my next blog post and I started to create a new workflow service in Visual Studio.  But apparently the designer came up with an exception for me:

Workflow Designer encountered problems with your document
Please check the document for invalid content, namespaces, references or reference loops.

'\' is an unexpected token. The expected token is ';'. Line 3, position 99.

After opening the XAML view, I noticed the full path of the xamlx file was added to the xml in the sad:XamlDebuggerXmlReader.FileName attribute of the sequence (main element).  And there it appeared that the fileName was not well-encoded, resulting in invalid XML, because of the usage of '&' sign.  (I added my blog tests in a folder with name R&D …)

The solution to this issue was to manually escape the R&D with R&amp;D string.

Off course, one could argue why the ‘source code’ or ‘model’ of a Workflow service needs to maintain a reference to a physical file on a developers machine (in source safe, everyone on the same project can check out to different locations…)

Just wanted to share this one.

Posted in: AppFabric | Workflow

Tags: , ,


By sam
August 11, 2010 at 2:12 PM

Recently I was in Redmond for the BizTalk VTS Summit, with a bunch of colleague BizTalk experts from all over the world.  During one of the discussions we had, a question came up about the fact that it seemed that to host HTTP endpoints, it is required to have IIS as the real host configured.

After my suggestion that is was perfectly possible to bypass IIS in this process, it looked that quite a number of attendees didn’t know about this.  And that’s the reason why I decided to add it to our blog…

WCF-Custom vs WCF-CustomIsolated

First of all, I think it is a best practice to avoid using the non-WCF-custom adapters (like WCF-WSHttp, etc).  I always suggest colleagues and customers to use the WCF-Custom or WCF-CustomIsolated adapter, since they are the only adapters that provide the maximum capabilities of WCF in BizTalk.  The other WCF-* adapters only provide a subset of the various binding and behavior settings, specific for their binding, which results in an adapter change, when a more advanced setting is needed one day.

The WCF-Custom adapter, is the adapter that is used to host WCF endpoints inside BizTalk.  The WCF-Isolated adapter is hosted in a BizTalk Isolated Host, which is typically IIS.

The BizTalk WCF Service Publishing wizard

To expose an orchestration or a schema as a WCF service in BizTalk, the BizTalk WCF Service Publishing wizard is the typical way to use.  In this wizard, the orchestration or schema needs to be selected and a choice between three adapters is possible: WCF-BasicHttp, WCF-WSHttp, WCF-CustomIsolated. 

The last step of the wizard is used to create a web directory in IIS, where the BizTalk svc file will be created that hosts the custom WCF Service Host that will link through to the BizTalk Receive location. 

WCF Service type WCF Service Location

Unfortunately, the WCF Publishing wizard does not allow to select the ‘In-Process’ adapters.  All of the three adapters/bindings are only available through an isolated host and required IIS.

Hosting the endpoint in the BizTalk process

To host the endpoint inside the BizTalk process, we need to manually create the WCF receive location.  To do so, we just need to select the WCF-Custom adapter and use the desired binding: BasicHttpBinding or WsHttpBinding. 

The following steps need to be used for this:

  1. Create a new receive location with the desired name
  2. Select the WCF-Custom adapter and open the properties for this adapter
  3. Specify an address for the endpoint (picture 1) Take into account that when IIS is already running on the machine, you might need to specify a different available port.
  4. Select your binding (or use the customBinding for full flexibility) in the Binding tab page. (picture 2) and set all desired binding properties to their correct setting.
  5. In the Messages tab page, you can also specify that failed request messages need to be suspended and that exceptions should be returned to the consumer. (picture 3)

wcf1 wcf2 wcf3

Metadata publication

One downside of this way of work is the metadata publishing.  If you would query the exposed endpoint for the WSDL, you would get to see the WSDL of the generic BizTalk WCF Service Host with the 5 operations.

Therefore, it is needed to publish the metadata endpoint to IIS and provide that endpoint to the consumers of your in-process service.  But this way of work, is similar to the other protocols (like netMsmq, netTcp…)

Advantages

  • Consistent approach for all binding types, independent of protocol.
  • No extra configuration / deployment needed (specific IIS security on IIS application pools, etc)
  • Performance (no extra hop)

Sam Vanhoutte, CODit

Posted in: BizTalk | WCF

Tags: , ,


By sam
June 17, 2010 at 9:37 AM

Since the latest release of the Windows Azure Development Kit (June), Azure provides support for .NET 4 applications, which is a real important step from the point of adoption, I believe.

 

The first thing we wanted to try was to host a XAMLX Workflow Service in a web role on Azure.

Example workflow service

I created a standard Workflow Service that accepted two parameters, on  one operation (Multiply) and returns the result of the multiplication to the client.  This service was called Calc.xamlx.

 

These are the steps I followed to make my service available.  I added the exceptions, because that’s typically what users will search for J

 

Enable visualization of errors

 

Standard behavior of web roles, is to hide the exception for the users, browsing to a web page.  Therefore, it is advised to add the following in the system.web section of the web.config:

 

<customErrors mode="Off"/>

 

Configure handler for Workflow Services

 

The typical error one would get, when just adding the Workflow Service to your web role and trying to browse it, is the following:

 

The requested url '/calc.xamlx' hosts a XAML document with root element type 'System.ServiceModel.Activities.WorkflowService'; but no http handler is configured for this root element type. Please check the configuration file and make sure that the 'system.xaml.hosting/httpHandlers' section exists and a http handler is configured for root element type 'System.ServiceModel.Activities.WorkflowService'.

 

We need to specify the correct HTTP handler that needs to be used for XAMLX files.  Therefore, we link the workflow services and activities to the correct Workflow Service ServiceModel handler.

 

To solve this, the following needs to be added to the web.config.

 

<configuration>
       <configSections>
             <sectionGroup name="system.xaml.hosting" type="System.Xaml.Hosting.Configuration.XamlHostingSectionGroup, System.Xaml.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
                   <section name="httpHandlers" type="System.Xaml.Hosting.Configuration.XamlHostingSection, System.Xaml.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
             </sectionGroup>
       </configSections>
       <!-- Removed other sections for clarity -–>
       <system.xaml.hosting>
             <httpHandlers>
                    <add xamlRootElementType="System.ServiceModel.Activities.WorkflowService, System.ServiceModel.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" httpHandlerType="System.ServiceModel.Activities.Activation.ServiceModelActivitiesActivationHandlerAsync, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
                    <add xamlRootElementType="System.Activities.Activity, System.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" httpHandlerType="System.ServiceModel.Activities.Activation.ServiceModelActivitiesActivationHandlerAsync, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
             </httpHandlers>
       </system.xaml.hosting>
</configuration>

 


Enabling metadata exposure of the workflow service

 

To enable consumers of our workflow service to generate their proxy classes, we want to expose the WSDL metadata of the service, by providing the following configuration section in the web.config.

 

Notice the simplicity of configuration, compared to WCF3.5.  Making use of the default behaviors, allows us to only specify what we want to override.

 

<system.serviceModel>
       <serviceHostingEnvironment multipleSiteBindingsEnabled="true" >
             <serviceActivations>
                    <add relativeAddress="~/Calc.xamlx" service="Calc.xamlx"  factory="System.ServiceModel.Activities.Activation.WorkflowServiceHostFactory"/>
  
          </serviceActivations>
       </serviceHostingEnvironment>
       <behaviors>
             <serviceBehaviors>
                    <behavior>
                           <serviceMetadata httpGetEnabled="true"/>
                    </behavior>
             </serviceBehaviors>
       </behaviors>
</system.serviceModel>

 

Testing and publishing

After successfully testing locally in the Azure Development Fabric, I uploaded and deployed the package, using the new Tools in Visual Studio to my Azure test account.

Sam Vanhoutte, CODit

Posted in: AppFabric | Azure | WCF | Workflow

Tags:


By sam
June 4, 2010 at 6:04 AM

Yesterday’s post showed the usage of the new BizTalk mapper activity in Workflow Services and how it made these workflows more declarative and drastically reduced the amount of assignment code that was typically required without this new feature.

Another interesting BizTalk feature that is made available in AppFabric workflows is the LOB (Line of Business) connectivity.  This functionality gets installed with the new BizTalk WCF LOB Adapter pack.

This post will show how this feature is used in the Workflow designer.  I will be using the SQL LOB adapter, because that’s the easiest to demonstrate.  (No SAP or Oracle test system available at this time).  I continue on the workflow that was created in the previous post.

Metadata generation

1.       Right-clicking the workflow project, will show the Add Adapter Service Reference… menu item. 
 

 

2.       This shows the familiar Add Adapter Service Reference dialog box.  (Don’t you all agree this tool still looks too much of ‘Form1/Button1’ app? J).  After selecting the sqlBinding and providing the ServerName and DataBaseName, the connection was made.

3.       This showed all the available metadata for this connection.  It is possible to select stored procedures or tables that will be used in the process.

 

4.       Since the LoanRequest needs to be inserted in the database table, the Client contract type was specified and the correct table (LoanRequests) and operation (Insert) were selected.

 

Using the LOB activity.

 

1.       After clicking OK and performing a rebuild on the project, a new custom activity was added to the Workflow Designer toolbox.  Each operation (Insert, Update …) that was selected results in a specific activity that is part of a category with the database object name.

2.       Dragging this activity on the canvas, shows that the following parameters can be specified on the shape.

 

3.       I only declared the variable ‘saveLoanResult’ that represents the records that should be added to the database.   This variable was linked with the Rows parameter of the InsertActivity shape and is an Array of LoanRequest objects.

4.       The InsertResult parameter would return the result of the database activity, but this parameter is optional, so I did not link it with a variable here.

 

5.       The BizTalk mapper activity was added right before the InsertActivity shape.  Here, I defined a mapping between the loanRequest and the databaseInsert.

6.       Compiling the project and executing the workflow, resulted in a new record in my database table.
 

 

 

Conclusion

The power of connectivity and adapter is now made available to the AppFabric platform in a standardized and user-friendly way.  It is now also easy to connect to various LOB systems, databases and host systems (using the BizTalk Adapters for Host Systems). 

What is not clear at this point is how the licensing will work for these AppFabric features.  But more information about that can probably be expected by the time of the public release.

Sam Vanhoutte

 

Posted in: AppFabric | WCF | Workflow

Tags: , ,


By sam
June 2, 2010 at 4:00 PM

Introduction

As described in the following wiki white paper on the social technet site (http://social.technet.microsoft.com/wiki/contents/articles/biztalk-appfabric-better-together.aspx) there is a nice new feature that gets installed through the released beta of BizTalk 2010.  Two capabilities of BizTalk Server are made available to WF 4.0!  This is about the BizTalk mapper and the Line of Business adapters (like SQL, Oracle, SAP…).

These features are also described in the blog post of Richard Seroter: post of Richard Seroter, (http://seroter.wordpress.com/2010/05/24/using-the-new-biztalk-mapper-shape-in-a-windows-workflow-service/). 

This is a first article in a series of three that is about these features.  Three articles will be posted in the coming days:

1.       Using the BizTalk mapper in Workflow

2.       Using the LOB Adapter functionality in Workflows

3.       Performance impact of the mapper shape, compared to code mapping.

The BizTalk mapper used in workflow services.

It happens a lot that data structures that are exposed through web services are different from the contracts and object types that need to be consumed by that service. 

During one of the demos I gave lately, I showed how an AppFabric workflow service was used to compose and consume three different other web services.  Allthough the customer really liked the pattern and the performance, he felt it was a bit too technical and too much code was involved to instantiate the web service requests and objects for the different services.  They were right (I needed to use too much assign shapes and different variables).

Luckily, we have a good answer to this at this moment, through the BizTalk mapper workflow activity.  It makes these workflows more model-driven and less code-oriented.

Installing the activities

It is important to know that the activities are only available in the Workflow designer toolbox, when installing the BizTalk LOB Adapter pack!  They are not part of the BizTalk 2010 installable and it looks like the installer of the adapter pack is checking if BizTalk 2010 is available to see if he should make the activities available.

Sample workflow service

The scenario I’ll be working out in this post is the exposing of a service that will call another web service.  This service will implement some specific logic and will also hide and abstract the actual names and contracts of the 'backend-service’.  The functionality we provide through this service is a loanrequest, where a consumer can request a loan and gets response with a result. 

The exposed contracts  

[DataContract]
    public class LoanRequest
    {
        [DataMember]
        public string CustomerName { get; set; }
        [DataMember]
        public long Amount { get; set; }
        [DataMember]
        public int Duration { get; set; }
        [DataMember]
        public LoanPart[] Parts { get; set; }
    }
    [DataContract]
    public class LoanPart
    {
        [DataMember]
        public LoanPartType PartType { get; set; }
        [DataMember]
        public long Amount { get; set; }
    }
    [DataContract]
    public enum LoanPartType
    {
        [EnumMember]
        Standard = 0,
        [EnumMember]
        Budget = 1,
        [EnumMember]
        Green = 2
    }
    [DataContract]
    public class LoanResponse
    {
        [DataMember]
        public double Intrest { get; set; }
        [DataMember]
        public double Variance { get; set; }
        [DataMember]
        public bool Approved { get; set; }
        [DataMember]
        public string Description { get; set; }
    }

 

Designing and beginning the workflow service

1.       After adding a new workflow service, I changed the action and namespace on the ReceiveRequest activity. 

2.       I also defined two variables: loanRequest and loanResponse that apply to their corresponding DataContract message types.  These are linked to the ReceiveRequest and SendResponse activities.

Adding a service reference to the ‘backend service’.

1.       Right-clicking the project and selecting Add Service Reference, pops up the dialog where I am linking to the WSDL of my web service.
 

2.       After a rebuild of this project, a new custom activity is added to my toolbox that can be used to call the web service operation.  If my web service would have had multiple operations, multiple activities would have been added, one for each operation.  They totally hide the implementation of doing this web service call.

 

3.       Now, two new variables get defined that represent the request and response to the backend service.  (notice the uppercased host-like names J)
 

4.       Dragging the LOANSIM activity to the designer canvas allows us to link the variables to the Activity Parameters of this web service operation call.

 

Use the BizTalk mapper activity to map request and response variables

1.       The Mapper activity is available in the BizTalk category in the Workflow Toolbox.  I just dragged two instances of this activity to the canvas, just before and after the LOANSIM activity.

2.       Once the mapper is dragged to the canvas, the input and output data types need to be configured, using the type picker dropdown.  This will be used to define the BizTalk map inputs and outputs.

 

3.       After this, the correct variables need to be linked and configured to their corresponding parameter.

 

 

4.       Clicking the Edit button on the activity, allows us to automatically generate a new BizTalk map that will use these types or we can reuse an existing map.

5.       Creating a new map, results in a new Biztalk mapper being opened.  Various schemas are being generated and added to the project in a specific sub folder.  The nice new BizTalk mapper can be used to make the mapping between both objects.  If required, custom XSLT functionality can also be used for this.

 


6.       The above logic has been done for both the request and the response messages.

 

 

Resulting workflow

The resulting workflow looks like the following:

 

Conclusion

The AppFabric + BizTalk better together story is a compelling offering that brings the BizTalk features closer to the AppFabric and Workflow runtime.  Considering that WF will be more and more important in the future of BizTalk and AppFabric, I believe this is a good step forward and we might see more of these things happen in the future.

Does this make AppFabric a free BizTalk Server?  No, it can be used to implement various scenarios that were done in BizTalk previously, but it still does not provide the rich management, deployment capabilities.  We still cannot accept flat file messages or EDI.  There is no pub/sub or direct binding.  Yet?

 

Sam Vanhoutte,-