Microsoft Integration Weekly Update: March 11, 2019

Microsoft Integration Weekly Update: March 11, 2019

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!

 

Microsoft Announcements and Updates

Community Blog Posts

 

Videos

 

Podcasts

How get started with iPaaS design & development in Azure?

  • Robust Cloud Integration with Azure
  • Microsoft Azure for Developers: What to Use When
  • Azure Logic Apps: Getting Started
  • Azure Logic Apps: Fundamentals
  • Microsoft Azure Developer: Creating Enterprise Logic Apps
  • Microsoft Azure API Management Essentials
  • Azure Functions Fundamentals
  • Cloud Design Patterns for Azure: Availability and Resilience
  • Architecting for High Availability in Microsoft Azure

Feedback

Hope this would be helpful. Please feel free to reach out to me with your feedback and questions.

Achieving a Consolidated Monitoring View Using Custom Widgets

Achieving a Consolidated Monitoring View Using Custom Widgets

BizTalk360 Monitoring

BizTalk360 comes with out of box capabilities to monitor BizTalk Artifacts, BizTalk Environment, Queues (IBM, Azure Service Bus and MSMQ), File Location (File, FTP and SFTP) and so on. The Monitoring Dashboard represents the Monitoring Status in a nice graphical chart view. Different set of users like BizTalk Administrators, Operators, Technical members and Business users are using the monitoring features for their day to day activities. Users create multiple alarms to suffice their needs to monitor the health of their BizTalk environment.

While users are monitoring the multiple alarms, they must keep an eye on multiple dashboards. It is a cumbersome task if a user takes care of more than two Alarms. Based on this requirement, few customers have requested for consolidate view of alarms. In this article, we are going through the process of how you can create a consolidated view of multiple alarms using Custom Widgets.

Scenarios

BizTalk360 users are configuring the alarms based on their business vertical or alignment to their process. There have been different patterns in alarm configurations. We can see some of the commonly used patterns;

  • Integration-based alarm configuration

Configuring BizTalk Artifacts, Web Endpoints, Queues, File Location etc. of integration in an alarm.

  • Role-based alarm configuration

BizTalk Administrators will look after infrastructure settings like Disk, System Resources, Host Instances and configure in an alarm BizTalk Operators can configure BizTalk Artifacts and other entities in a single alarm

  • Entity-based alarm configuration

For instance, users can configure all their Queues (IBM/Azure Service Bus) in an alarm. Similarly, they can configure Web Endpoints, Infrastructure (Disks, System Resources) in separate alarms.

Based on the above patterns, Role-based and Entity-based alarms can have a single view of multiple alarms in which you can monitor all the entities. When you follow the Integration-based alarm pattern, then entities like Application Artifacts, Azure Service Queues and BizTalk Server health activities are in different alarms.

Many organizations follow the Integration pattern by grouping all the related artefacts in an alarm. In this scenario, users (BizTalk Operators/BizTalk Technician) must monitor multiple alarms. For Instance, BizTalk Operators looking after BizTalk Artifacts or Developers responsible to monitor Azure Service Bus Queues will have to monitor the multiple alarms. Let’s see how to overcome this challenge by using custom widgets to group multiple alarms.

Consolidated Dashboard

The Monitoring Dashboard is one of the most used features among the users to monitor BizTalk Environments and Artifacts in BizTalk360. An enriched monitoring capability while using Custom widgets to group the multiple alarms to get a single view based on business or team members role.

Custom Widgets are a powerful feature in BizTalk360, as such widgets will provide the opportunity to meet their business scenarios. Many customers adopted Custom Widgets to provide solutions to end users.

Following are a few illustrated scenarios of grouping alarms when it is configured based on integrations

  1. Azure Service Bus Queues
  2. BizTalk Application Artifacts
  3. BizTalk Environment Health

In this article we take one of these scenarios, to show how users can achieve the grouping alarms using Custom Widgets

Azure Service Bus Queues

Custom Widgets used BizTalk360 Secure SQL Query API’s to fetch all Azure Service Bus Queues Monitoring Status from BizTalk360 Database. A user can select the filter with different alarms they want to group.

By default, the user can see only the unhealthy queues in an environment. If they set the Enable Healthy Queue option, they will be able to view all queues in the tree nodes. The Azure Service Bus Queues Custom Widget will fetch the information from Secure SQL Query with a refresh interval which is configured in the script of the custom widget.

Follow the below steps to achieve the Custom Widget’s script;

1. Secure SQL Query

Create the Secure SQL Query to fetch the monitoring status of Azure Service Bus Queues in the environment. To know more about how you can execute Secure SQL Queries using custom widgets, refer to this article.

2. Custom Widget Script

Create the initial variables, Place holders and SQL Query to call the BizTalk360 API method in the Custom Widget’s script

// BEGIN User variables
    azureQueueRefresh = 20;
    username = "`username_812414`"; 
    password = "`password_701422`"; 
    environmentId = "`productionenvid_189308`";    
 queryId = "8eea2771-10a7-44c6-8709-a597687434cf"; 
 queryName = "Azure ServiceBus Queues"; 
 sqlInstance = "kovai-bts";     
database = "BizTalk360"; 
    sqlQueryForAzureGraph = "Select AA.Id,AA.[Name],AME.MonitorStatus,AME.ExecutionResult from [dbo].[b360_alert_MonitorExecution] AME Inner Join[dbo].[b360_alert_Alarm] AA ON AME.AlarmId = AA.Id and AME.MonitorGroupType = 'Queues' WHERE AME.LastExecutionTime = (SELECT MAX(LastExecutionTime) from [dbo].[b360_alert_MonitorExecution] WHERE MonitorGroupType = 'Queues' and AA.IsAlertDisabled='false' and AlarmId = AA.Id and LastExecutionTime >= DATEADD(MINUTE,-60,GETUTCDATE())) AND AME.EnvironmentId ='`productionenvid_189308`'"; // The SQL Query which needs to be executed from the custom Widget
    bt360server = "biztalk360.westus.cloudapp.azure.com"; // Name of the BizTalk360 server (needed to do an API call to execute the SQL query
    //Mention the created alarm details and the respective partner name to display in the graph.
    AlarmDetails = [
        { AlarmName: "Threshold-1", PartnerName: "Air India" },
        { AlarmName: "Threshold-2", PartnerName: "British Airways" },
        { AlarmName: "Threshold-3", PartnerName: "DHL" },
		{ AlarmName: "BizTalk360 Default Alarm1", PartnerName: "Jet Airways" }
    ];
    // END User variables

3. GO JS Framework

BizTalk360 uses the GO JS Framework- Organization chart to represent the monitoring hierarchical view in the UI. It will display the organization chart structure as Azure Service Bus Queue node as a root node, Integration friendly name as second level node and Queue threshold violation details as a child node. You can control the nodes expand/collapse capability of through the custom widget code.

4. Filter Options

Users can able to filter the data based on the selected alarms or the option to show healthy queues. By default, users can see only unhealthy Azure Service Bus Queues. Similarly, other scenarios are implemented through custom widgets. To get the full source code of the Custom widgets you can download it from our GitHub Project.

Summary

We hope this article is useful in grouping the multiple alarms into a single view in an environment. This will bring you more control over the custom development you may want to achieve.

Get started with the free 30 days trial. For any queries/feedback please write to us [email protected].

The post Achieving a Consolidated Monitoring View Using Custom Widgets appeared first on BizTalk360.

Faster Service Fabric Deployments with PowerShell

Faster Service Fabric Deployments with PowerShell

Presentation

A few weeks ago I had the great privilege of presenting a 60 minute breakout session at Microsoft Ignite | The Tour in Sydney. It was thrilling to have over 200 people registered to see my topic “Seamless Deployments with Azure Service Fabric”, especially in the massive Convention Centre.

In the session I demonstrated the self-healing capabilities of Service Fabric by introducing a bug in the code and then attempting a rolling upgrade. It was impressive to see how Service Fabric detected the bug after the first node was upgraded and then immediately started rolling it back.

As you can imagine, it took a fair amount of practice to get the demo smooth and functioning within the tight time limits of the average audience attention span. (In fact, I had to learn how to tweak both the cluster and the application health check settings to shorten the interval – perhaps the subject of another blog post!) Naturally this also entailed frequently “resetting” the environment so that I could start over when things didn’t go quite as planned, or if I wanted to reset the version number. If you’ve ever worked with Service Fabric before you would know that deployments from Visual Studio (or Azure DevOps) can take a while; and undeploying an application from Service Fabric manually in the portal is painful!

For example, if I want to undeploy an application from a Service Fabric cluster in the web-based Service Fabric Explorer, I have to do the following in this order:

  1. imageRemove the service
  2. Remove the application
  3. Unregister the application type
  4. Remove the application package

What becomes really annoying is that each step elicits a confirmation prompt where you need to type the name of the artefact you want to remove! That gets old pretty fast.

Thankfully, there is an alternative. Service Fabric offers a number of different ways to deploy applications, including Visual Studio, Azure CLI, and PowerShell.  Underneath the covers I expect these all make use of the REST API. But in my case I found the simplest and most efficient choice was PowerShell. Using the documented commands, it is easy to create a script that will deploy or undeploy your application package in seconds. And I mean seconds! It was astounding to see how quickly the undeploy script could tear down the application!

The script I created is available in my demo code on GitHub. I’ll walk through some of it here.

Pre-requisites

First, it is necessary to have the Azure PowerShell installed. This is normally included when you install the Service Fabric SDK, but you must enable execution of the scripts first.

Second, in order for the Deploy_SFApplication.ps1 script to work, you must have already packaged the application. You do this by right-clicking the Service Fabric project in Visual Studio (not the solution file!) and selecting “Package”. The path to this package is a mandatory parameter for this script. The Undeploy_SFApplication.ps1 script does not require this.

Parameters

The make the scripts reusable with the minimum amount of changes, I’ve parameterized all of the potentially variable settings:

Parameter Name Description Example/Default Value
path This is the path to your packaged application. (This parameter is not required for the Undeploy_SFApplication.ps1 script) C:ReposDemosVoting_v3VotingpkgDebug
imageStorePath Where you want the package stored when uploaded in Service Fabric. Typically this can be the application name, perhaps with a version. Voting
appTypeName Usually the app name with “Type” appended VotingType
appName Must be prepended with “fabric:/” fabric:/Voting
appVersion IMPORTANT! Cannot deploy the same version already existing, it will fail 1.0.0
ServerCommonName If using your local development cluster, just “localhost”.
Otherwise, if in Azure,  “CLUSTER_NAME.REGION.cloudapp.azure.com”
myCluster.australiaeast.cloudapp.azure.com
clusterAddress Append the port number to the $ServerCommonName variable, usually 19000 $(ServerCommonName):19000

resolves to:
myCluster.australiaeast.cloudapp.azure.com:19000

thumb The thumbprint of the certificate used for a secured cluster (not generally required for a local cluster)
NOTE: The script currently sets the location of the certificate in the current user’s personal store. However this could be easily parameterized.
https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-retrieve-the-thumbprint-of-a-certificate

Script Execution Steps

First thing we do is import the appropriate module:

Import-Module "$ENV:ProgramFilesMicrosoft SDKsService FabricToolsPSModuleServiceFabricSDKServiceFabricSDK.psm1"

Then it’s simply a matter of following using the documented commands, substituting the variables as appropriate in order to:

  • Connect to the cluster
  • Upload the package to the package store
  • Register the application type
  • Create the application instance

My Deploy_SFApplication.ps1 script also prints out the application instance details as well as the associated service instance details:

The Undeploy_SFApplication.ps1 script does much the same, except in reverse of course:

  • Connect to the cluster
  • Remove the application instance
  • Unregister the application type
  • Remove the application package

The use of the –force flag means that when you run this script you will NOT be prompted for confirmation like this:

2019-03-02_21-37-50

Whilst the deployment script takes about 20 seconds for this Voting application, the undeploy script takes less than five seconds!

As mentioned previously, the scripts are freely downloadable along with the rest of the demo code on GitHub. I’m no PowerShell guru, so I’m sure there’s plenty of room for improvement. Send me a pull request if you have any suggestions! And feel free to get in touch if you have any questions.

This post was originally published on Deloitte’s Platform Engineering blog.

Determine Ready to Run / Active Service Instance Details with Custom Widgets

Determine Ready to Run / Active Service Instance Details with Custom Widgets

When messages flow into the BizTalk Server, the messages may get persisted in BizTalk Server’s MessageBox database. For a healthy BizTalk environment, it’s important to keep an eye on the number of service instances in the environment.For example, having a large number of suspended service instances will bloat your message box database and adversely affect the overall performance of your environment.

Administrator should always  keep an eye on the service instances count via the BizTalk Administrator group hub page. The person who is monitoring this, need to be a BizTalk expert and understand the importance of each state. The group hub page only displays the instance count and it won’t tell you whether this is still at a healthy level. Whereas with BizTalk360 you can set the Warning and Error threshold levels (instance counts) for each states at application level. Once the number of instances count increases above the threshold, the system will send notification alert.

Also, the administrator can set up an alarm like “If there are >20 Suspended Service Instances between 09:00 AM and 05:00 PM, resume all the instances”. He can simply log in to the BizTalk360 Data Monitoring Dashboard to see the status of the message box data for the day. He can also set up email notifications for the alarm. By doing so, the administrator eliminates the need to often log in to the BizTalk360 application and check for the status of the service instances.

Custom widget to list all service instance details which are active for a long period

Custom Widget is one of the interesting and powerful features available in BizTalk360. With a custom widget, users can easily integrate third-party portals like Power BI, Sales Force or internal portals. You can also easily display Secure SQL Queries query results , monitor BizTalk Artefact statuses etc.

For instance, if a host instance is too busy to process all its associated service instances , then those instances will be in “Ready to Run” state until the host instance has available resources. When this situation remains for a longer timeframe, the service instances are going to get accumulated, thereby bloating the message box.

With the below script you can quickly create a custom widget to look up the number of service instances which are in the active state for a particular period of time. Say, the administrator can easily check service instance details which are in the Ready to Run or Active state for more than 15 minutes.

Creating such a widget, consists of the following steps:

  1. Create a Secure SQL Query
  2. Bind the SQL Query result to the custom widget

Both steps are described below.

1) Create Secure SQL Query

The below query retrieves the Service Instances which are in the Active state for more than 30 minutes.

DECLARE @dt DATETIME = ( DATEADD(MINUTES,-30,GETUTCDATE()))

exec ops_OperateOnInstances @snOperation=0 ,@fMultiMessagebox=0 ,@uidInstanceID='00000000-0000-0000-0000-000000000000', @nvcApplication=N'', @snApplicationOperator=0, @nvcHost=N'' ,@snHostOperator=0,@nServiceClass=111,@snServiceClassOperator=0,@uidServiceType='00000000-0000-0000-0000-000000000000', @snServiceTypeOperator=0, @nStatus=2, @snStatusOperator=1 ,@nPendingOperation=1 ,@snPendingOperationOperator=0,@dtPendingOperationTimeFrom='1753-01-01 00:00:00', @dtPendingOperationTimeUntil='9999-12-31 23:59:59.997', @dtStartFrom='1753-01-01 00:00:00', @dtStartUntil=@dt ,@nvcErrorCode=N'',  @snErrorCodeOperator=0 ,@nvcErrorDescription=N'' ,@snErrorDescriptionOperator=0,@nvcURI=N'',@snURIOperator=0,@dtStartSuspend='1753-01-01 00:00:00', @dtEndSuspend='9999-12-31 23:59:59.997', @nvcAdapter=N'', @snAdapterOperator=0, @nGroupingCriteria=0, @nGroupingMinCount=0,@nMaxMatches=10,@uidAccessorID='*******',@nIsMasterMsgBox=0;

2)Bind the SQL Query result to a custom widget 

You can create the custom widget and use below code. Don’t forget to include your environment details like the credentials of the BizTalk360 service account, etc.

<div id="WidgetScroll" style="top:30px;" data-bind="addScrollBar: WidgetScroll, scrollCallback: 'false'">
<table class="table table-lists">
<thead>
<tr>
<th style="width:30%">Application Name</th>
<th style="width:30%">Instance Id </th>
<th style="width:30%"> Service ID</th>
<th style="width:30%">Created Date</th>
<th style="width:30%">State</th>
</tr>
</thead>
<tbody>
<!-- ko if: (ServiceInstanceDetails()) -->
<!-- ko foreach: ServiceInstanceDetails() -->
<tr>
<td data-bind="text: nvcName"></td>
<td data-bind="text: uidInstanceID"></td>
<td data-bind="text: uidServiceID"></td>
<td data-bind="text: dtCreated"></td>
<td data-bind="text: nState"></td>
</tr>
<!-- /ko -->
<!-- /ko -->
</tbody>
</table>
</div>
<script>
// BEGIN User variables
username = ""; // BizTalk360 service account
password = ""; // Password of BizTalk360 service account
environmentId = ""; // BizTalk360 Environment ID (take from SSMS or API Documentation)
queryId = ""; // Id of the Secure SQL Query (take from SSMS)
queryName = ""; // Name of the Secure SQL Query as it is stored under Operations/Secure SQL Query
sqlInstance = ""; // SQL Instance against which the SQL Query must be executed
database = ""; // Database against which the SQL Query must be executed
sqlQuery = " " // The Secure SQL Query created in step1
bt360server = ""; // Name of the Server where biztalk360 is hosted
// END User variables

url = 'http://' + bt360server + '/BizTalk360/Services.REST/BizTalkGroupService.svc/ExecuteCustomSQLQuery';
ServiceInstanceDetails = ko.observable();

x2js = new X2JS({ attributePrefix: '', arrayAccessForm: "property", arrayAccessFormPaths: ["root.records.record"] });

ServiceInstanceDetailsList = function () {
var _this = this;
_this.getServiceInstanceDetails(function (data) {

var results = x2js.xml_str2json(data.queryResult);
if (Array.isArray(results.root.records.record)){
ko.utils.arrayForEach(results.root.records.record,function(item){

switch (item.nState){
case "1":
item.nState="Ready to Run";
break;
case "2":
item.nState="Active";
break;
}
});
_this.ServiceInstanceDetails(results.root.records.record);
}
else {
_this.ServiceInstanceDetails([results.root.records.record]);
}
});
};
getServiceInstanceDetails = function (callback) {
var _this = this;
$.ajax({
dataType: "json",
url: _this.url,
type: "POST",
contentType: "application/json",
username: _this.username,
password: _this.password,
data:
'{"context":{"environmentSettings":{"id":"' +
_this.environmentId +
'","licenseEdition":0},"callerReference":"REST-SAMPLE"},"query":{"id":"' +
_this.queryId +
'","name":"' +
_this.queryName +
'","sqlInstance":"' +
_this.sqlInstance +
'","database":"' +
_this.database +
'","sqlQuery":"' +
_this.sqlQuery +
'","isGlobal":false}}',
cache: false,
success: function (data) {
callback(data);
},
error: function (xhr, ajaxOptions, thrownError) {
alert(xhr.status);
alert(xhr.responseText);
},
});
};
ServiceInstanceDetailsList();
</script>

After you have created the custom widget and properly provided your environment details, it will look similar to the picture below.

We have written multiple articles about the capabilities of custom widgets, both in our blog, but also in the Documentation portal. You can check them out below:

Conclusion

It has been extremely beneficial to ensure the environment is healthy. With this custom widget you can easily get a clear insight about long running service instance details in a single view. If you have a particular scenario in which custom widgets could be useful, but you don’t know how to set this up, feel free to contact us at [email protected].

Persistence and Recoverability on the Microsoft Platform

Recently I added an article to the integration playbook which compares the different approaches used for Durability, Persistence and Retry across the various microsoft technologies such as BizTalk, Logic Apps, Event Grid, Event Hubs, Service Bus Messaging and Functions

You can read more here – https://www.integration-playbook.io/docs/durable-messaging-on-the-microsoft-platform

Message Correlation on Microsoft Integration Platform

Ive recently added an article in the Integration Playbook talking about how messages can be correlated between processing instances. In particular this compares the approach in BizTalk against the approach you can use in Logic Apps by combining Logic Apps and Service Bus

More info – https://www.integration-playbook.io/docs/message-correlation

Microsoft Integration Weekly Update: Feb 25, 2019

Microsoft Integration Weekly Update: Feb 25, 2019

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!

Feedback

Hope this would be helpful. Please feel free to reach out to me with your feedback and questions.

Advertisements

Using BizTalk360 for alarm notification statistics

Using BizTalk360 for alarm notification statistics

It is nothing new that BizTalk360 enables you to set up automated monitoring for BizTalk. This includes the deployed BizTalk application artifacts and different kind of endpoints. You can even track the processing which is taking place in your BizTalk environment.

For each unexpected situation for which you have set up monitoring, you can receive notifications via for example email, SMS/Text message or the Event Log. Besides that, BizTalk360 also provides Notification channels to connect to products like Slack, Microsoft Teams and HP Operations Manager. In case you are using ServiceNow, you can even have BizTalk360 generate incidents into that product! If that still does not meet your requirements, you can use a Web Hook, or the easy-to-use API provided by the product to integrate with your systems.
The BizTalk360 database contains information about the transmitted notifications.

Collecting Alarm statistics

Recently, we had a call with a consultancy company which manages several BizTalk environments for their clients. These clients are using BizTalk360 for operating and monitoring the BizTalk environments.

The consultancy company was interested in knowing whether BizTalk360 provides any statistics about all the alarms which were triggered over time. This kind of statistics serves different goals. On one side, this kind of information gives insight in components which frequently have outage, enabling to take counter measures. On the other side, this can also be used to provide such information to the client of the consultancy company as a kind of reporting.

In this blog post we describe how you can use the information in the BizTalk360 database, to show statistics about which alarms have been transmitting which kind of notifications over time.

Showing SQL data in BizTalk360

As already mentioned, the information about the transmitted notifications is stored in the BizTalk360 database. BizTalk360 provides different capabilities to show data which is stored in SQL Server databases. These capabilities are:

• Secure SQL Queries – see https://docs.biztalk360.com/docs/secure-sql-queries
• Custom Widgets – see https://docs.biztalk360.com/docs/creating-a-custom-widget-for-executing-secure-sql-queries

Depending on the requirements how you want to be able to view that data, you can use either or both features, but the main characteristics are that Secure SQL Queries are mainly used manually, where Custom Widgets can become shown on a dashboard and the output will be refreshed automatically.

The information we will be using in this blog post is stored in a table called b360_alert_notify_ToBeNotified. The content of that table is specific to Threshold monitoring. If you need more detailed information about Data Monitoring statistics, you should have a look at a different table. Based on the b360_alert_notify_ToBeNotified table, you can write a SQL query which looks like below:

SELECT aa.Name AS 'Alarm Name',
an.NotificationRequiredType AS 'Notification Type',
COUNT(an.AlarmId) AS Count,
MAX(CreatedDateTime) AS 'Most recent'
FROM b360_alert_notify_ToBeNotified an
RIGHT OUTER JOIN b360_alert_Alarm aa ON an.AlarmId = aa.Id
WHERE (an.NotificationRequiredType <> 'Regular')
GROUP BY aa.Name, an.NotificationRequiredType
order by [Alarm Name]

In above query, notifications of type ‘Regular’ have been left out. Regular notifications refer to the Health alarms which can be received at a specified time, to show the state of all the mapped artifacts of an alarm. For this scenario, that information is considered as not relevant.

Retention period

It is good to know, that without any filters, the data will be shown according the Purging policy for Alert & Maintenance History. This policy can be viewed and reconfigured in the Settings area, under BizTalk360 Health, in the Purging Policy screen.

Obviously, in case you do want to see a bit more limited data set, you can add WHERE conditions based on the CreatedDateTime field.

Showing Alarm statistics as a Secure SQL Query

When you create a Secure SQL Query for this, the output of the query can look like below.

As you can see, the query shows information about the name of the alarm, which kind of notification is involved, the count of notifications and the most recent date/time a notification has been transmitted, for that alarm/notification type combination.

If you want to know more about how to create Secure SQL Queries, you can check out the Documentation portal about this feature.

Having this kind of information as a Secure SQL Query can be very handy. You have the information easily at hand by accessing that query and run it. The results can also be exported to a .CSV file.

Showing Alarm statistics as a Custom Widget

If you want to have an even better experience, you can consider creating a Custom Widget for this. Doing so, enables you to have this information on a dashboard and because of the behavior of these dashboards, the widget will be automatically refreshed. Besides that, by a simple click, you can export the entire dashboard, which could contain more statistical widgets, to a PDF file and provide it to your clients.

Based on the query we have seen earlier in this article such a widget will look like below.

Once the widget has been added to a dashboard, the query will automatically be executed, and the data will be refreshed each minute. If needed, you can change the refresh interval in the script of the widget.

If you want to read more about creating such Custom Widgets, check the Documentation portal for it. It contains some detailed articles about this topic.

Conclusion

We have shown another way on how BizTalk360 can be useful. So, if you have any questions about this capability, or anything else related to BizTalk360 feel free to contact us. Why not give BizTalk360 a try! You can download a free trial which contains all the features for a limited time.

Author: Lex Hegt

Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360. View all posts by Lex Hegt

Terminating Dehydrated Service instances through BizTalk360 PowerShell Notification channel

Terminating Dehydrated Service instances through BizTalk360 PowerShell Notification channel

BizTalk360 has introduced notification channels from its major version release V8.0. One of the most greeted features from our customers. With the introduction of this capability, it’s easy to send alerts to any external systems like your ticketing system, internal databases, calling REST endpoints or executing PowerShell scripts.

One of the most powerful capabilities is to use an API, to enable you to create notification channels for connecting to your own systems. The PowerShell notification channel allows you to execute a PowerShell script, each time an alarm is triggered when the threshold is crossed.

During business transactions in mission-critical BizTalk Server environments, if any of the service instances are waiting for response messages, they will be turned to the dehydrated state. There might be valid reasons why such service instances are not needed anymore. So, as a BizTalk administrator, you should keep an eye on these instances in their environments to avoid further critical business consequences.

BizTalk360 provides Monitoring capabilities for dehydrated service instances and it sends periodic alerts via different notification channels. One such channel is the PowerShell Notification channel.

This blog post will give you an insight about how to terminate the dehydrated service instances through the PowerShell notification channel in BizTalk360, just by configuring it with the Alarms.

Steps to implement the PowerShell Notification Channel

1. Create the PowerShell script
2. Configure the PowerShell notification channel
3. Configure the PowerShell notification channel with the Alarm

Creating the PowerShell script

To develop the PowerShell script, it is essential to identify the API’s which will take care of these actions.

Step 1:

Retrieve the dehydrated service instances from the Message Box using the below API.
http://localhost/BizTalk360/Services.REST/BizTalkQueryService.svc/ExecuteServiceInstanceQuery

Code Snippet


import-Module Microsoft.PowerShell.Management
$username = "DomainUserName"
$password = "ABC1236890"
$password_base64 = ConvertTo-SecureString $password -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential ($username, $password_base64)
$body_ExecuteServiceInstanceQuery='{
"context":{
"callerReference":"REST-SAMPLE",
"environmentSettings":{
"id":"3beb9328-c435-47ed-8c51-a406117e632b",
"licenseEdition":0
}
},
"query":{
"compositeFilter":{
"filterDescriptorCollection":[
{
"member":"Instance Status",
"filterAvailableMember":[
{
"name":"Application",
"alias":"Application Name",
"dataType": 1,
"isList":true,
"isAutoComplete":false
},
{
"name":"CreationTime",
"alias":"Creation Time",
"dataType":0,
"isList":false,
"isAutoComplete":false
},
{
"name":"GroupResultsBy",
"alias": "Group Results By",
"dataType": 1,
"isList": true,
"isAutoComplete": false
},
{
"name": "HostName",
"alias": "Host Name",
"dataType": 1,
"isList": true,
"isAutoComplete": false
},
{
"name": "InstanceStatus",
"alias": "Instance Status",
"dataType": 1,
"isList": true,
"isAutoComplete": false
},
{
"name": "ServiceClass",
"alias": "Service Class",
"dataType": 1,
"isList": true,
"isAutoComplete": false
},
{
"name": "ServiceInstanceID",
"alias": "Service Instance ID",
"dataType": 1,
"isList": false,
"isAutoComplete": false
},
{
"name": "ServiceName",
"alias": "Service Name",
"dataType": 1,
"isList": true,
"isAutoComplete": false
},
{
"name": "ServiceTypeID",
"alias": "ServiceType ID",
"dataType": 1,
"isList": false,
"isAutoComplete": false
}
],
"memberType": 1,
"filterOperator": 2,
"value": "Dehydrated",
"progressIndicator": false,
"validationError": "",
"isValid": true,
"tempValue": ""
}
]
},
"maxMatches": "10",
"queryType": 0
},
"maxMatches": "10"
}'
$headers=@{"Content-Type"="application/json"}
$uri="http://BT360SUP03/BizTalk360/Services.REST/BizTalkQueryService.svc/ExecuteServiceInstanceQuery"
$response = Invoke-WebRequest -Uri $uri -Headers $headers -Method Post -Body $body_ExecuteServiceInstanceQuery -Credential $creds

Step 2:

Pass the retrieved dehydrated service instances for the termination process to the below API.

http://localhost/BizTalk360//Services.REST/BizTalkQueryService.svc/ExecuteServiceInstanceOperation

Code Snippet


$ExecuteServiceInstanceQueryobj = ConvertFrom-Json $response
if (!$ExecuteServiceInstanceQueryobj.serviceInstances) {write-Host "There are no dehydrated service instances for termination"}

foreach ($serviceinstance in $ExecuteServiceInstanceQueryobj.serviceInstances)
{
$body_ExecuteServiceInstanceOperation='{
"context":{
"callerReference":"REST-SAMPLE",
"environmentSettings":{
"id":"3beb9328-c435-47ed-8c51-a406117e632b",
"licenseEdition":0
}
},
"serviceInstances":[
{
"ServiceName": "'+$($serviceinstance.ServiceName)+'",
"ServiceClass": "Orchestration",
"StatusDisplayText": "Dehydrated",
"Application":"'+$($serviceinstance.application)+'",
"ServiceInstanceID":"'+$($serviceinstance.serviceInstanceID)+'"
}
],
"operation": 1
}'
$headers1=@{"Content-Type"="application/json"}
$uri1="http://localhost/BizTalk360//Services.REST/BizTalkQueryService.svc/ExecuteServiceInstanceOperation"
$response1 = Invoke-WebRequest -Uri $uri1 -Headers $headers1 -Method Post -Body $body_ExecuteServiceInstanceOperation -Credential $creds
$ExecuteServiceInstanceQueryobj = ConvertFrom-Json $response
}

Points to Remember

Following are the parameters need to be changed as per your environment configuration.

  1. Service Account credentials for UserName
  2. Password
  3. Environment Id
  4. URI

As mentioned in the introduction section, BizTalk360 exposes its APIs and can be found in the section Settings -> API documentation.

Terminating Dehydrated Service instances - API Documentation screen

Configuring the PowerShell Notification channel

Once the PowerShell script has been created, the next step is to configure it with the notification channel in BizTalk360.The PowerShell notification channel can be found in Settings -> Monitoring Notification Channels ->B360.Notifier.PowerShellNotification.

Terminating Dehydrated Service instances - Configure PowerShell Notification channel

Select the notification channel and click on the “Configure” button on the top menu bar. In the Configuration Notification Channel section, enter the location of the script which has been created for terminating the dehydrated service instances and click on the Configure button. Now, the PowerShell script has been configured with the BizTalk360 notification channel.

Terminating Dehydrated Service instances - Associate the Powershell Script Path

Associating the PowerShell Notification Channel with Alarms

The next primary step is to Map the notification channel with the Alarms for further execution and configure the Threshold violation settings, as how frequent you want to terminate the dehydrated service instances from your environment. Based on the settings, BizTalk360 will terminate the dehydrated service instances in your BizTalk Server environment.

Terminating Dehydrated Service instances - Alarm Configuration with PowerShell Notification Channel

Terminating Dehydrated Service instances - Threshold Alarm Settings

Conclusion

We strongly believe BizTalk360 has transformed the way you do your work. It is a very common situation where administrators depend on various tools like BizTalk admin console, SQL queries and other custom build tools to monitor their BizTalk Environment. But with this capability “PowerShell Notification Channel”, administrators can create their own scripts and automate their daily activities. In this blog post, we have explained one such scenario we can accommodate with BizTalk360. This capability is not restricted for some functionalities, the component is generically implemented in the product where our customers can achieve a lot more business scenarios by using this powerful capability.

Do try BizTalk360 one-stop monitoring tool for your BizTalk Server.

Author: Mekala Ramesh

Lead QA & Product Support at BizTalk360 – Having around 8 years of experience in software testing & customer support field with the strong knowledge in SDLC and STLC phases. Specialized in various types of testing methodologies. Passionate tester, who always want to deliver the software product with the best quality to the end customers. Possess strong knowledge, to establish the testing process from scratch. Playing a pivotal role in BizTalk360 is making me deliver the product to every customer in a delicious way. View all posts by Mekala Ramesh

Microsoft Integration Weekly Update: Feb 18, 2019

Microsoft Integration Weekly Update: Feb 18, 2019

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!

Feedback

Hope this would be helpful. Please feel free to reach out to me with your feedback and questions.

Advertisements