by Gautam | Jun 11, 2017 | BizTalk Community Blogs via Syndication
Do you feel difficult to keep up to date on all the frequent updates and announcements in the Microsoft Integration platform?
Integration weekly update can be your solution. It’s a weekly update on the topics related to Integration – enterprise integration, robust & scalable messaging capabilities and Citizen Integration capabilities empowered by Microsoft platform to deliver value to the business.
If you want to receive these updates weekly, then don’t forget to Subscribe!
On-Premise Integration:
Cloud and Hybrid Integration:
Feedback
Hope this would be helpful. Please feel free to let me know your feedback on the Integration weekly series.
by Sandro Pereira | Jun 6, 2017 | BizTalk Community Blogs via Syndication
During my sessions about BizTalk Server Tips and Tricks, I normally ask: What RosettaNet, ESB or UDDI have in common? And the answer is: they all are BizTalk optional features that are not part of the primary installation process, you need to execute “secondary” installation processes to add theses features. These installation processes will create BizTalk custom databases for supporting all of these new optional features. But the big questions here are: do you think that these databases are being backed up? And if not, how to backup (other) BizTalk Custom Databases?
Do you think that these databases are being backed up?
To respond this first question, the answer is: No!
Because these BizTalk custom databases (we are calling “custom databases” because they are supporting optional features that are not part of the primary installation process) are not installed by default with BizTalk Server, they are not included in the default list of databases to be marked and backed up by the Backup BizTalk Server job. The default list of databases that are, normally, being backed up by the Backup BizTalk Server job are:
- BAMAlertsApplication
- BAMPrimaryImport
- BizTalkDTADb
- BizTalkMgmtDb
- BizTalkMsgBoxDb
- BizTalkRuleEngineDb
- SSODB
How to Backup (other) BizTalk Custom Databases?
If you want the Backup BizTalk Server job to back up these additional BizTalk custom databases, you must manually add the databases to the Backup BizTalk Server job.
You can achieve this by:
- Taking Windows Explorer and browse to the “Schema” directory on the BizTalk installation folder, normally:
- C:Program Files (x86)Microsoft BizTalk Server <version>Schema
- Run “Backup_Setup_All_Tables.sql” and next “Backup_Setup_All_Procs.sql” against all your BizTalk custom databases that you want to back up. This creates the necessary table, procedures, roles and assigns permissions to the stored procedures.
- After that you need need to modify the adm_OtherBackupDatabases table, in the BizTalk Management (BizTalkMgmtDb) database, to include a row for each of the new BizTalk custom databases
- Type the new server and database names in the corresponding columns, as shown in the following tab
- DefaultDatabaseName: The friendly name of your custom database.
- DatabaseName: The name of your custom database.
- ServerName: The name of the computer running SQL Server.
- BTSServerName: The name of the BizTalk Server. This value is not used, but it must contain a value nonetheless.
To complete the process, you, mandatory, need to force Backup BizTalk Server (BizTalkMgmtDb) job to perform a full backup of the databases, otherwise you will receive the following error:
- BACKUP LOG cannot be performed because there is no current database backup. [SQLSTATE 42000] (Error 4214) BACKUP LOG is terminating abnormally. [SQLSTATE 42000] (Error 3013)
To do that you need:
- Execute the “sp_ForceFullBackup” stored procedure present in the BizTalkMgmtDb database.
The next time you run the Backup BizTalk Server job, it will back up all your BizTalk custom databases.
Note: I will not recommend you to add any of your application support custom databases to the Backup BizTalk Server job since they may interfere with the execution times of this job. If the Backup BizTalk Server job starts to take a long time to execute, it may also affect the overall performance of the BizTalk platform.
Stay tuned for new BizTalk Server Tips and Tricks!
Check out the first blog of the series BizTalk Server Tips and Tricks: Enabling BAM Add-In for Excel 2016.
Author: Sandro Pereira
Sandro Pereira is an Azure MVP and works as an Integration consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. View all posts by Sandro Pereira
by Sandro Pereira | Jun 5, 2017 | BizTalk Community Blogs via Syndication
Recently, I was writing a new article “BizTalk Server Tips and Tricks: How to Backup (other) BizTalk Custom Databases” (that will be release soon as a guest post in BizTalk360 Blog) that explain you how you can configure the Backup BizTalk Server (BizTalkMgmtDb) job to back up additional BizTalk custom databases (RosettaNet, ESB Toolkit, …), when I got an error message on the job saying: BACKUP LOG cannot be performed because there is no current database backup. [SQLSTATE 42000] (Error 4214). The full error was this:
Date 6/5/2017 2:30:00 PM
Log Job History (Backup BizTalk Server (BizTalkMgmtDb))
Step ID 3
Server BTS02
Job Name Backup BizTalk Server (BizTalkMgmtDb)
Step Name MarkAndBackupLog
Duration 00:00:01
Sql Severity 16
Sql Message ID 3014
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0
Message
Executed as user: domain/username. Processed 1 pages for database ‘BAMPrimaryImport’, file ‘BAMPrimaryImport_log’ on file 1. [SQLSTATE 01000] (Message 4035) BACKUP LOG successfully processed 1 pages in 0.037 seconds (0.118 MB/sec). [SQLSTATE 01000] (Message 3014) Processed 12 pages for database ‘BizTalkDTADb’, file ‘BizTalkDTADb_log’ on file 1. [SQLSTATE 01000] (Message 4035) BACKUP LOG successfully processed 12 pages in 0.051 seconds (1.790 MB/sec). [SQLSTATE 01000] (Message 3014) Processed 9 pages for database ‘BizTalkMgmtDb’, file ‘BizTalkMgmtDb_log’ on file 1. [SQLSTATE 01000] (Message 4035) BACKUP LOG successfully processed 9 pages in 0.054 seconds (1.283 MB/sec). [SQLSTATE 01000] (Message 3014) Processed 67 pages for database ‘BizTalkMsgBoxDb’, file ‘BizTalkMsgBoxDb_log’ on file 1. [SQLSTATE 01000] (Message 4035) BACKUP LOG successfully processed 67 pages in 0.101 seconds (5.129 MB/sec). [SQLSTATE 01000] (Message 3014) Processed 1 pages for database ‘BizTalkRuleEngineDb’, file ‘BizTalkRuleEngineDb_log’ on file 1. [SQLSTATE 01000] (Message 4035) BACKUP LOG cannot be performed because there is no current database backup. [SQLSTATE 42000] (Error 4214) BACKUP LOG is terminating abnormally. [SQLSTATE 42000] (Error 3013) BACKUP LOG successfully processed 1 pages in 0.051 seconds (0.086 MB/sec). [SQLSTATE 01000] (Error 3014). The step failed.
Cause
If you take attention to the error message, you will notice that the job failed in the third task: MarkAndBackupLog, that is responsible for performing the backup’s the BizTalk Server databases logs.
You need to remember that by default Backup BizTalk Server (BizTalkMgmtDb) job only makes a full backup of the databases once a day and each 15 minutes a backup of the databases logs. However, to be able to perform a back up of the log from a particular database, it needs that a previous full backup has been performed and register in the “adm_BackupHistory” table in the BizTalkMgmtDb database. You can validate by executing the following script:
USE [BizTalkMgmtDb]
SELECT DISTINCT [DatabaseName]
FROM [BizTalkMgmtDb].[dbo].[adm_BackupHistory]
In my case, I was configuring an additional database to be backed up via the Backup BizTalk Server (BizTalkMgmtDb) job, and at that time, the full backup of the BizTalk Databases had already occurred.
Solution
To fix the problem of BACKUP LOG cannot be performed by the Backup BizTalk Server job, you need to:
- Execute the “sp_ForceFullBackup” stored procedure present in the BizTalkMgmtDb database.
USE [BizTalkMgmtDb]
EXEC sp_ForceFullBackup
The next time you run the Backup BizTalk Server job, it will back up all BizTalk databases including all your BizTalk custom databases and it will be able them to execute the third task: MarkAndBackupLog, and therefore execute successfully the job once again.
Author: Sandro Pereira
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira
by Gautam | Jun 4, 2017 | BizTalk Community Blogs via Syndication
Do you feel difficult to keep up to date on all the frequent updates and announcements in the Microsoft Integration platform?
Integration weekly update can be your solution. It’s a weekly update on the topics related to Integration – enterprise integration, robust & scalable messaging capabilities and Citizen Integration capabilities empowered by Microsoft platform to deliver value to the business.
If you want to receive these updates weekly, then don’t forget to Subscribe!
On-Premise Integration:
Cloud and Hybrid Integration:
Feedback
Hope this would be helpful. Please feel free to let me know your feedback on the Integration weekly series.
by Sriram Hariharan | Jun 4, 2017 | BizTalk Community Blogs via Syndication
This blog will give you a recap of the feature content that was discussed as a part of Episode 22 of Middleware Friday. In this episode, Kent Weare discussed a small, yet very interesting feature in Azure Logic Apps – the Retry Policy.
Logic App Retry Policy
To understand the Retry Policy better, let’s assume we have an endpoint that is consumed by Logic Apps. If the endpoint has some intermittent issues, and the initial request fails to execute, the number of retries will be attempted based on the “retry count” default settings. By default, the retry action will execute 4 additional times over 20-second intervals. The retry policy applies to intermittent failure HTTP codes like 408, 429, 5xx series. You can define the retry policy as follows:
"retryPolicy" : {
"type": "<type-of-retry-policy>",
"interval": <retry-interval>,
"count": <number-of-retry-attempts>
}
The maximum number of retry attempts that can be made is 4. If you try tweaking the retry count in the JSON, during the Logic App execution you will notice an exception as “The provided retry count of ‘value’ is not valid. The retry count must be a positive number no greater than ‘4’“. Similarly, the maximum delay for a retry can be set to 1 hour while the minimum delay is 5 seconds. Azure Logic Apps uses ISO 8601 standards for the above mentioned time durations and you need to define the interval in one of the following formats –
| PnYnMnDTnHnMnS |
| PnW |
| P<date>T<time> |
Demo – With Default Retry Mechanism
Kent demonstrated the Azure Logic App Retry Policy with the help of the following Logic App example –
Prerequisite: Create a Logic App before proceeding with the steps shown below
- First, let’s start with a Blank Logic App. In the Logic App designer, we will get started with creating a simple HTTP request trigger.
- Next, we will create an HTTP POST method and give a fake URL (URI) to allow the retry mechanism to kick in
- Finally, an HTTP response action with the status code of 200 to complete the Logic App
When we execute the Logic App, you will notice that the default retry mechanism (4 attempts, once every 20 seconds) will kick in.
After about 70 seconds, the fourth retry is performed.
Finally, after 80 seconds, the Logic App execution will fail and the corresponding error will be displayed in the Logic App Designer.
You can alter the retry mechanism by entering the code view and modifying the code with the values as shown previously in the blog post.
Therefore, the demo clearly shows how the retry policy works out of the box in Logic Apps and how you can customize the retry policy within its limits. You can watch the video of this session here –
Feedback Survey
If you have any specific topics of interest at Middleware Friday, you can fill in this survey. Alternatively, you can tweet at @MiddlewareFri or drop an email to middlewarefriday@gmail.com with your topics of preference.
You can watch the Middleware Friday sessions here.
Author: Sriram Hariharan
Sriram Hariharan is the Senior Technical and Content Writer at BizTalk360. He has over 9 years of experience working as documentation specialist for different products and domains. Writing is his passion and he believes in the following quote – “As wings are for an aircraft, a technical document is for a product — be it a product document, user guide, or release notes”. View all posts by Sriram Hariharan
