In majority of the organisation, you’ll have anywhere between 2 to 10 BizTalk environments. Typically Production, Staging, UAT, Performance, System Integration etc. From time to time you may require to keep all the monitoring configuration between environment in sync. Or there may be a scenario where you first configure and test all your BizTalk monitoring requirements in a pre-production or UAT environment and once you are happy you wanted to migrate it into production.
To address all these kind of requirements, we are introducing the ability to export and import your BizTalk monitoring configuration from one environment to another from BizTalk360 version 7.9 onwards.
Exporting your configuration
Exporting your monitoring configuration is fairly straight forward task and it typically requires only one click. You navigate to “Manage Alarms” section in your BizTalk360 installation and simply click the “Export” button. All the configurations will be packaged and a zip file will get downloaded automatically. Inside the zip file it contains bunch of json files, but as a user you do not need to worry too much about it.
Importing your configuration
Once the alarm is exported from an environment, it can then be easily imported into any environment. Importing is slightly more involved operation than exporting. When you are importing a configuration file, there are few challenges. For obvious reasons, some of the environment details are going to differ between the original exported environment and the environment where you are importing. Example: BizTalk Server names, SQL Server names, SQL Instance names etc. In addition there are other challenges like, what happens when the artifact is not present in the destination environment. Example: “PO Processing Application” is present in your QA environment, but not in production. It’s also important to have a very robust exception handling mechanism when you are doing bulk import operations to avoid risk of overwriting, corrupting configuration etc.
The import capability takes care of all the above challenges and make it easy and intutive to perform the import task. Let’s take a quick look at step-by-step process in importing the configuration file.
Import operation is a 5 step process, as shown below
First you need to choose the configuration file, then select the monitoring alarms you wanted to import, map any discrepancies between environments (like BizTalk , SQL server names), verify the configuration by looking at the summary and finally import and see the result. If any exceptions reported address it.
Step 1: Select configuration file: This is very straight forward, you simply click on the “Select Files” button to choose the configuration file or you can drag and drop the configuration file into the user interface as shown below.
Step 2: Choose the alarms you wanted to import: Once the configuration file is selected, the wizard will automatically move forward into step 2 and display all the alarms that’s present in the configuration file. You can then either choose to import all of them or select only the specific alarms you wanted to import as shown below.
there are few options while selecting the alarms, by default all the alarms is kept in disabled status to avoid sending unnecessary notification after import, you may wanted to review all the configuration before enabling it. But if you are confident with the configuration you can enable it here. The alarm name can be modified by just hovering over relevant alarm names and editing it. You may want to rename certain alarms between environments. The screen also gives you option to handle duplicates, the default behaviour is to raise it as error when duplicates detected, but if you are confident you can force it to overwrite. You can perform setting the status and overwrite option in bulk to save some time.
Step 3: Map environment discrepancies: Once you have chosen relevant alarms to import, the system will detect if there are any mapping required between source system and destination system. The three common things that will require mapping are BizTalk Server, SQL Server and SQL Server Instance names, since they will for sure differ between environments. The third screen “Map Environment” will give user the option to do this mapping as shown below.
On the LHS (source environment) it will list all the server names found in the source system (configuration file) and on the RHS it will display all the available servers in the environment (destination environment), the user can simply choose the required mappings.
Step 4: Review the summary: On the fourth screen based on the selection and mapping so far will give a final summary report, it will also give bit more detail on each alarm, example what artifacts are been configured in each one of them (you need to expand the down arrow to view it). Once you are happy you can simply click on the “Import’ button
Step 5: Result summary and exception handling: Once the import button is clicked, all necessary back end calls will be made and the result of the import process will be shown. You can view all the details like which artifacts are imported, what mapping applied etc. If there are any errors during import process in certain alarms those will be displayed as well.
Once you close the import wizard, you will be redirected to “Manage Alarms” screen and you can view all the imported alarms.
There are various benefits in the export/import capability. One of the obvious benefit is moving your configuration from one environment to another. In addition we can also see other useful scenarios like, if you are a consulting firm working with multiple BizTalk customers, you can maintain a master monitoring configuration file, whenever you wanted to configure BizTalk monitoring for your customer, you simply install BizTalk360, import the master configuration file you have and just map the environments settings. With this process you’ll be able to setup and configure monitoring in some record 20-30 minutes time.