WABS February 2014 – Backup and Restore

Posted: February 24, 2014  |  Categories: Operations Uncategorized WABS Windows Azure BizTalk Services
Tags:

Windows Azure BizTalk Services (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 WABS. 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 blog post will discuss the latter two new features available for WABS. Both features will enhance the ability for operation professional responsible for business continuity of the service. The first release of WABS offered support for backup and restore through a REST API. With the new release the capability is now available through the Windows Azure Portal. The backup and restore can be monitored through the Windows Azure Management Service as WABS is now integrated with the Azure Operations Logs, which enables auditing of management tasks for the BizTalk Service. Note that the Windows Azure Management Service logs not only the operations of the BizTalk Service, but also other services used in Windows Azure. 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 Windows Azure Portal:

  • In the Windows 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 popup where you need to specify the backup name and the blob storage account.

  • 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 .

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

  • 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.

  • 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 Windows Azure Portal:

  • In the Windows 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.

  • 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 Windows Azure Management Service, see also the MSDN article BizTalk Services: Troubleshoot using operation logs  .

Backup the BizTalk Service using the Windows 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 Windows 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 Windows 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.

After the backup is completed you can look into the operation logs in the Windows 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 Windows Azure Portal or through the REST API for WABS.

Restore using the Windows Azure Management Portal

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

  • Select the BizTalk Service in the Windows 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.

  • 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.
  • In edition you can select a different one in case you want to migrate your service and its solutions to a new version.
  • The tracking database can be the same of a new one.

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

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

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

  • 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.

  • 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  .

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

      Restore the BizTalk Service using the Windows 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 Windows 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 Windows 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 Windows Azure BizTalk Services (see also TechNet Wiki article Managing Windows 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.

      After the backup is completed you can look into the operation logs in the Windows Azure Management Service. You will notice when you select Operations Logs that the information will be loaded in a grid. Enhancement of backup and restore operation in Windows Azure will provide the operation professional better means of controlling WABS. He/she doesn’t have to rely on REST API, but has both options available now. Options are using the Windows 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 WABS.
      Cheers,
      Steef-Jan

      Author: Steef-Jan Wiggers

      Steef-Jan Wiggers is all in on Microsoft Azure, Integration, and Data Science. He has over 15 years’ experience in a wide variety of scenarios such as custom .NET solution development, overseeing large enterprise integrations, building web services, managing projects, designing web services, experimenting with data, SQL Server database administration, and consulting. Steef-Jan loves challenges in the Microsoft playing field combining it with his domain knowledge in energy, utility, banking, insurance, healthcare, agriculture, (local) government, bio-sciences, retail, travel, and logistics. He is very active in the community as a blogger, TechNet Wiki author, book author, and global public speaker. For these efforts, Microsoft has recognized him a Microsoft MVP for the past 8 years.

      turbo360

      Back to Top