Introduction

Azure BizTalk Services (formerly called Windows Azure BizTalk Services or WABS) provides capabilities for EAI and B2B in the cloud. This relative new service was made available for customers in November 2013. Microsoft committed to have a release cadence for new features every three months. Currently in February 2014 Microsoft has released new features for Azure BizTalk Services. These new features are:

  • EDIFACT Protocol Support and X12 Schema Updates
  • Pulling Messages from Service Bus Queues and Topics
  • Service Bus Shared Access Signatures (SAS) support with Service Bus Queues and Topics
  • BizTalk Adapter Services No Longer Needs SQL On Premises
  • Backup and Restore Support
  • Operation Log Support
This article will discuss the latter two new features available for Azure BizTalk Services. Both features will enhance the ability for operation professional responsible for business continuity of the service.

Backup and restore feature

The first release of Azure BizTalk Services offered support for backup and restore through an REST API. With the new release the capability is now available through the Azure Portal. The backup and restore can be monitored through the Azure Management Service. The Azure BizTalk Service is now integrated with the Azure Operations Logs, which enables auditing of management tasks for the BizTalk Service. Note that the Azure Management Service logs not only the operations of the BizTalk Service, but also other services used in Azure.

Backup

The backup procedure only applies for the basic, standard, and premium version of the BizTalk Service. Backup can be done manually (ad-hoc) or automatic (scheduled).

Ad-hoc backup

The following steps describe the way the backup is performed manually (or called ad-hoc backup) on the Microsoft Azure Portal:

  • In the Microsoft Azure Portal – BizTalk Service select the BizTalk Service you want to back up.
  • In the menu bar on the bottom select BACK UP.
  • A Windows will pop-up where you need to specify the backup name and the blob storage account.


Figure 1 - Specification of the Back up BizTalk Service Storage.

  • Specify a backup name. The name must be a string between 3 and 63 characters and start with a letter or number, must be lowercase containing only letters, numbers, and hyphens. Note that the name cannot contain two consecutive hyphens. Subsequently choose the appropriate blob storage account.
  • Click on Check Mark.
  • Backing up of the BizTalk Service will start. Basically now a snapshot of the BizTalk Service and its configuration will be taken. What exactly is being backed up is described in MSDN BizTalk Services: Backup and Restore Section What gets backed up.


Figure 2 - Backing up the BizTalk Service.

  • Duration of this operation is a couple of minutes.
  • After the backup is completed you can look into the operation logs in the Microsoft Azure Management Service. You will notice when you select Operations Logs that information will be loaded in a grid.


Figure 3 - Operation Log of the BizTalk Service Backup.

  • Notice that with in the operation log you can specify the subscriptions, services, date/time windows, status, and type as filters for search queries.
  • In your storage account you can verify the backup of the service. Select the Storage, choose the specified storage account used for the backup, select the container and then the container named after the backup.


Figure 4 - Backup files of the BizTalk Service Backup.

  • The backup results into a group of files that contain configuration, and so on. See MSDN BizTalk Services: Backup and Restore Section What gets backed up.

Scheduled backup

A scheduled backup can be configured in the configure tab of your BizTalk Service. The following steps describe the way the backup is performed automatically (or called scheduled backup) on the Microsoft Azure Portal:

  • In the Microsoft Azure Portal – BizTalk Service select the BizTalk Service you want to configure the scheduled backup for.
  • Default status of the backup is NONE. You can select AUTOMATIC and then you have to specify when the service needs to be backed, and what frequency.
  • In case you select AUTOMATIC than details for scheduled backup will appear.


Figure 5 - Specification of settings for a scheduled BizTalk Service Backup.

  • You need to specify the storage account, similar to manual backup operation.
  • Subsequently you specify the frequency, start date and time. Note that the subsequent backups will start at the specified time. When a backup is in progress, you will not be able to change the configuration of the service!
  • Finally you specify the retention time of the number of days for which backups will be retained before being deleted from the storage account. Note that longer retention period will result in higher storage costs for your storage account.
  • After specifying the scheduled backup you can click save in the menu bar below.

When a scheduled job runs a container will be created in the specified storage account with a name in the format of BizTalk Service name-date-time. In case the backup fails you can look into the operation logs of the Microsoft Azure Management Service, see also the MSDN article BizTalk Services: Troubleshoot using operation logs.

Backup the BizTalk Service using the Microsoft Azure REST Management API

A backup can also be performed by using the REST API operation for backing up a BizTalk Service (see also TechNet Wiki article Managing Azure BizTalk Services with REST API). The method for the operation is POST and the format of the URL is:

https://management.core.windows.net/{subscription-id}/cloudservices/{cloud-service-name}/resources/biztalkservices/biztalk/{resource-name}?comp=backup

The {subscription-id} is your Azure subscription ID, which can be found by going to the settings page of your subscription the Microsoft Azure Portal. The {cloud-service-name} can be derived through the get cloud service operation. Finally the resource {resource-name} is the name of your BizTalk Service. With the REST POST operation you have to add a RESTAPIBody to the operation call. This body will contain the following information:
<ServiceBackupSettings>
<BackupStoreConnectionString>BlobEndpoint=blobendpoint;QueueEndpoint=queueendpoint;TableEndpoint=tableendpoint;AccountName=accountname;AccountKey=accountkey;DefaultEndpointsProtocol=https</BackupStoreConnectionString>
  <BackupName>backup-2014-21-02</BackupName>
</ServiceBackupSettings>

These details basically mean the connection string to the storage account. See Storage account details and manage access key.

The BackupStoreConnectionString is the store in which BizTalk Services backup is created and the BackupName is a lowercase name, limited between 3 and 63 characters, starting with a letter or number, and can contain only letters, numbers, and the dash (-) character. After every dash (-) the character must be immediately preceded and followed by a letter or number; consecutive dashes are not permitted in container names. Therefore the format would be like:

backup-2014-21-02

Below you will see how the operation is performed using a custom solution that leverages the REST Management API.


Figure 6 - Backup of the BizTalk Service using the REST Management API.

After the backup is completed you can look into the operation logs in the Microsoft Azure Management Service. You will notice when you select Operations Logs that the information will be loaded in a grid.

Restore

A BizTalk Service can be restored from a backup. The backup restore can be useful for migration between versions or when a BizTalk Service requires to restored. You a backup from one version to the other according to the table below.

Original Version

New Version

Basic

Standard

Basic

Premium

Standard

Premium

The restore can be performed through the Microsoft Azure Portal or through the REST API for Azure BizTalk Services.

Restore using the Microsoft Azure Management Portal

The following steps describe the way the restore is performed manually in the Microsoft Azure Portal:

  • Select the BizTalk Service in the Microsoft Azure Portal.
  • Select NEW --> APPS SERVICE --> BIZTALK SERVICE-->RESTORE
  • A Window will appear where you have to specify details in three tabs. On the first you need to specify backup URL. A browse Windows will appear if you click the folder symbol in the BACKUP URL box. You navigate to the blob storage container where the backup file resides. You select the file and click open.


Figure 7 - Selecting the backup file.

  • Next you have to specify the BizTalk Service name, which cannot be same as BizTalk Service that has been backed up, unless the BizTalk Services has been deleted.
  • You specify the edition, where you can select a different one in case you want to migrate your service and its solutions to another edition (See table).
  • The tracking database can be the same of a new one.


Figure 8 - Specify the settings for restoring the BizTalk Service.

  • Next tab you specify a name of the tracking database and the server.
  • Subsequently you specify the credentials of the database.


Figure 9 - Specify the database settings.

  • In case you click CONFIGURE ADVANCED DATABASE SETTING a fourth tab will appear enabling you to specify the database edition, database size and collation.


Figure 10 - Specify the settings for a database.

  • In the final tab you specify the Monitoring/Archiving Storage Account and storage account name.


Figure 11 - Specifying the settings for storage.

  • Click the check mark to start the restore operation. The restore operation is similar to provisioning of the BizTalk Service. After 30 minutes the operation will be complete.


Figure 12 - Restoring the BizTalk Service.

  • Note that the BizTalk Service is in the suspend state after the restore is complete. The reason behind this is that you can make any configuration changes in your applications if necessary before you make the new environment functional. See also the MSDN article BizTalk Services: Backup and Restore section considerations after restore.


Figure 13 - BizTalk Service is in suspended state after the restore is complete.

  • After the restore is completed you can look into the operation logs in the Microsoft Azure Management Service. You will notice when you select Operations Logs that the information will be loaded in a grid.



Figure 14 - Operation Log of the BizTalk Service Restore.

Restore the BizTalk Service using the Microsoft Azure REST Management API

A restore can also be performed by using the REST API operation for restoring a BizTalk Service (see also TechNet Wiki article Managing Azure BizTalk Services with REST API). The method for the operation is PUT and the format of the URL is:

https://management.core.windows.net/{subscription-id}/cloudservices/{cloud-service-name}/resources/biztalkservices/biztalk/{resource-name}

The {subscription-id} is your Azure subscription ID, which can be found by going to the settings page of your subscription the Microsoft Azure Portal. The {cloud-service-name} can be derived through the get cloud service operation. Finally the resource {resource-name} is the name of your BizTalk Service. With the REST PUT operation you have to add a RESTAPIBody to the operation call. This body will contain the following information:

<Resource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <SchemaVersion>1.0</SchemaVersion>
  <Plan></Plan>
  <IntrinsicSettings>
    <ServiceSettings>
      <ServiceBackupSettings>
 
<BackupStoreConnectionString>BlobEndpoint=blobendpoint;QueueEndpoint=queueendpoint;TableEndpoint=tableendpoint;AccountName=accountname;AccountKey=accountkey;DefaultEndpointsProtocol=https</BackupStoreConnectionString>
        <BackupName>backup-2012-21-02</BackupName>
      </ServiceBackupSettings>  
      <CustomDomainUrl>example.com</CustomDomainUrl>
      <Edition>Premium</Edition>
      <ServiceCertificate>
        <Data>{certificate-in-serialized-form}</Data>
        <Password>{password}</Password>
      </ServiceCertificate>
       
<TrackingStoreConnectionString>Data Source=tcp:databaseservername.database.windows.net;Initial Catalog=databasename;Integrated Security=False;User ID=user1@databaseservername;Password=mypassword;Asynchronous Processing=True;Encrypt=True;TrustServerCertificate=False</TrackingStoreConnectionString>
 
<ArchivingStoreConnectionString>BlobEndpoint=blobendpoint;QueueEndpoint=queueendpoint;TableEndpoint=tableendpoint;AccountName=accountname;AccountKey=accountkey;DefaultEndpointsProtocol=https</ArchivingStoreConnectionString>
 
<MonitoringStoreConnectionString>BlobEndpoint=blobendpoint;QueueEndpoint=queueendpoint;TableEndpoint=tableendpoint;AccountName=accountname;AccountKey=accountkey;DefaultEndpointsProtocol=https</MonitoringStoreConnectionString>
       <ServiceAcsParameters>
         <Namespace>acssample</Namespace>
         <ManagementUserName>user</ManagementUserName>
         <ManagementPassword>password=</ManagementPassword>
       </ServiceAcsParameters>
     </ServiceSettings>
   </IntrinsicSettings>
</Resource>

The details you have specify in this body can also be found by performing the Get Cloud Service operation of the REST API for Microsoft Azure BizTalk Services (see also TechNet Wiki article Managing Azure BizTalk Services with REST API).

Below you will see how the operation is performed using a custom solution that leverages the REST Management API.



Figure 15 - Restore of the BizTalk Service using the REST Management API.

After the backup is completed you can look into the operation logs in the Microsoft Azure Management Service. You will notice when you select Operations Logs that the information will be loaded in a grid.

Wrap up

Enhancement of backup and restore operation in Microsoft Azure will provide the operation professional better means of controlling Azure BizTalk Services. He/she doesn’t have to rely on REST API, but has both options available now. Options are using the Microsoft Azure Portal and choose either for ad-hoc and/or scheduled backups or use REST API Operations using a custom solution that leverages the API. This article demonstrated the steps to carry out backup and restore through the Windows Azure Management Portal as well as performing the operation using the BizTalk Service REST API. The Management Service within the Windows Azure Portal provides the operation logs capability that is now also integrated with Azure BizTalk Services.

See Also

Another important place to find a huge amount of Azure BizTalk Services related articles is the TechNet Wiki itself. The best entry point is Azure BizTalk Services resources on the TechNet Wiki.

If you are also looking for BizTalk Server related articles, the best entry point is BizTalk Server Resources on the TechNet Wiki.