by Gautam | Feb 12, 2017 | BizTalk Community Blogs via Syndication
Are you struggling 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 Dan Toomey | Feb 10, 2017 | BizTalk Community Blogs via Syndication
“When it rains, it pours.”
Well, I must say I’ve had a pretty remarkable run the past few weeks! I can’t remember any point in my professional life where I’ve enjoyed so much reward and recognition in such a short time span.
For starters, after six weeks and probably 50-60 hours of study, I managed to pass my MS 70-533 Implementing Azure Infrastructure Solutions exam. Since I’d already passed the MS 79-532 Developing Azure Solutions exam a couple of month earlier, this earned me the coveted Microsoft Certified Solutions Associate (MCSA) qualification in Cloud Platform. I now have just one more exam to pass to earn the Microsoft Certified Solutions Expert (MCSE) qualification.
Then just last week I was granted my first Microsoft Most Valuable Professional (MVP) Award in Azure! This is incredibly exciting to say the least, and not only a surprise to myself to have been identified with so many incredibly accomplished leaders in the industry, but also to many others because of the timing. Microsoft has revamped the MVP program so that now awards will be granted every month instead of every quarter, and everyone will have their review date on July 1st. I’m looking forward to using my newfound benefits to contribute more to the community.
And if that wasn’t enough, this week Mexia promoted me to the position of Principal Consultant! Aside from the CEO (Dean Robertson), I am the longest serving employee, and the journey over the last seven and a half years has been nothing short of amazing. Seeing the company grow from just three of us into the current roster of nearly forty has been remarkable enough, but I’ve also watched us become a Microsoft Gold Partner and win a plethora of awards (including ranking #10 in the Australia’s Great Place to Work competition) along the way. Working with such an awesome team has afforded me unparalleled opportunities to grow as an IT professional, and I will strive to serve both our team and our clients to the best of my ability in this role.
So what else is on the horizon? Well for starters, next week I join the speaker list at Ignite Australia for the first time delivering a Level 300 Instructor-Led Lab in Azure Service Fabric. I’m also organising and presenting for the first ever Global Integration Bootcamp in Brisbane on 25th March, and doing the same for the fifth Global Azure Bootcamp on 22nd April. And somewhere in there I need to fit in that third Azure exam… It’s going to be a busy year!
by Saranya Ramakrishnan | Feb 10, 2017 | BizTalk Community Blogs via Syndication
Azure Logic Apps play a vital role in an integration platform. Keeping this in mind, we introduced ‘Azure Logic Apps Monitoring’ in BizTalk360 Version 8.1. In Version 8.3, we implemented ‘Azure Logic Apps Operations’ capability to improve the ease of use for users using Logic Apps and BizTalk360. With this functionality, users can Operate, Manage and Monitor Azure Logic App(s) from a single place. When you see a threshold violation of Logic Apps, you can rectify the problem from the BizTalk360 UI itself. You can save time to log in to the Azure Portal and manage your Logic Apps.
All the user needs to do to configure Logic Apps Operations capability is to add the Azure subscription in BizTalk360 UI and enable it for monitoring and operation. BizTalk360 also provides an option to work on multiple subscriptions simultaneously. Therefore, by adding the subscription in BizTalk360, users can view the list of available Logic Apps in that subscription along with its name, Access End Point, the current Status (Enabled or Disabled), Last Run, and other details such as Resource Group, Location, Run and Trigger history details and Success/Failure Run count.
Features of Logic Apps Operations
Enable/Disable Logic Apps: From BizTalk360 UI, users can enable/disable the Logic Apps that reflects the corresponding Logic App in the Azure Subscription. You can initiate bulk operations — enable/disable multiple Logic Apps in a single click.
Run Trigger: User can also trigger the Logic App action from the BizTalk360 UI. This action also supports the bulk operations.
Delete Logic Apps: User can delete single or multiple Logic Apps through a single click from BizTalk360 UI.
Note: The Azure Portal UI allows to operate (Enable/Disable, Delete, Run Trigger) on only one Logic App at a time, whereas from BizTalk360 UI user can initiate bulk operation (select multiple logic apps) in a single click.
Run and Trigger History details
Data like History and Runs are huge when it comes to real time scenarios/production use. For each Logic App, Run and Trigger history will maintain the last 30 records. The history details will be displayed in both list and graphical View.
List View
- Start and End time of Run/Trigger. Here the time format and time zone is based on user profile configuration.
- Run/Trigger status such as succeeded/failed, running/skipped/aborted
- Duration of each Run and Trigger
Graphical View
We have simplified the UI view of your Logic Apps details and redefined Runs and Trigger history into Graphical representations. With the graphical view, it becomes easy for the users to navigate and identify the date and time tracking.
The graphical view chart shows Logic Apps Runs in the “Y” axis and Date in the “X” axis. All basic graph operations such as zoom, hover are available in the graphical view. Additionally, you can print/download the chart.
Success and Failure Run count
Based on colour coding, you can know the Success and Failure Run counts instantly within the detail window of your Logic App.
Trigger and Action Status
Users can see the actual design of the Logic App in the Details View, say when it should be trigger and which actions are to be performed.
E.g : Trigger ‘When_a File_Is_created ’ ; Action – Email_File .
Licensing
If you are an existing user of BizTalk360, and using the Platinum tier license, you just need to upgrade to BizTalk360 Version 8.3 to use this feature. For customers using other licensing tier, if you would like to use/try this feature, please send an email to support@biztalk360.com to customize your license.
If you are new to BizTalk360 and like to explore the Logic Apps Operations capability, you can get started with the 14 day free trial of BizTalk360.
by mbrimble | Feb 7, 2017 | BizTalk Community Blogs via Syndication
February 8, 2017
No comments yet.
RSS feed for comments on this post. TrackBack URI
by Sandro Pereira | Feb 7, 2017 | BizTalk Community Blogs via Syndication
To finalize this series of posts about how to check what BizTalk Server <version> Cumulative Updates are installed in your Servers with PowerShell:
We just need to talk about BizTalk Server 2013 to cover the last 4 versions of the product. And I know some environments that still are running in this version, for this reason, it is still a valid and quite useful script.
This script is very similar to the script that I created for BizTalk Server 2010 because, in earlier versions, such as BizTalk Server 2010 and 2013, there were dedicated versions for BizTalk Server and BizTalk Adapter Pack. This has changed since BizTalk Server 2013 R2 where Microsoft decide to create Cumulative Updates for BizTalk Server, Adapter Pack, and Accelerators in a single resource and part of a single download.
PowerShell to check what BizTalk Server 2013 Cumulative Updates are installed in your Servers with PowerShell: This is a simple script that allows you to configure the template name of the cumulative updates, that will change from version to version, and will give you the list of all BizTalk Server 2013 cumulative updates installed on your machine:
This is the list of BizTalk Server 2013 Cumulative Update installed in this machine: BTS2013LAB01
- Microsoft BizTalk Server 2013 CU1
- Microsoft BizTalk Server 2013 CU2
This is the list of BizTalk Server 2013 Adapter Pack Cumulative Update installed in this machine: BTS2013LAB01
- BizTalk Adapter Pack 2013 CU1
The sample script (the link to the full script is available at the end of this post):
#Name template for BizTalk Server CU's for BizTalk Server 2013 (normally they are "Microsoft BizTalk Server 2013 CU#")
$CUNameTemplate = 'Microsoft BizTalk Server 2013 CU'
#The Wow6432 registry entry indicates that you're running a 64-bit version of Windows.
#It will use this key for 32-bit applications that run on a 64-bit version of Windows.
$keyResults = Get-ChildItem -path HKLM:SOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionUninstall -Recurse -ErrorAction SilentlyContinue | where { $_.Name -match $CUNameTemplate}
if($keyResults.Count -gt 0)
{
write-host "This is the list of BizTalk Server 2013 Cumulative Update installed in this machine: $env:computername"
}
else
{
write-host "There is the no BizTalk Server 2013 Cumulative Update installed in this machine: $env:computername"
}
foreach($keyItem in $keyResults)
{
if ($keyItem.GetValue("DisplayName") -like "*$CUNameTemplate*")
{
write-host "-" $keyItem.GetValue("DisplayName").ToString().Substring(0,$keyItem.GetValue("DisplayName").ToString().IndexOf(" CU")+4)
}
}
...
#Name template for BizTalk Server Adapter Pack CU's for BizTalk Server 2013 (normally they are "BizTalk Adapter Pack 2013 CU#")
$CUNameTemplate = 'BizTalk Adapter Pack 2013 CU'
#The Wow6432 registry entry indicates that you're running a 64-bit version of Windows.
#It will use this key for 32-bit applications that run on a 64-bit version of Windows.
$keyResults = Get-ChildItem -path HKLM:SOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionUninstall -Recurse -ErrorAction SilentlyContinue | where { $_.Name -match $CUNameTemplate}
...
THIS SQL SCRIPT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
Check all BizTalk 2013 Cumulative Updates installed in server with PowerShell (3 KB)
Microsoft | TechNet Gallery
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 michaelstephensonuk | Feb 7, 2017 | BizTalk Community Blogs via Syndication
Recently I have been thinking about a sample use case where you may want to expose legacy applications via a hybrid API but you have the challenge that the underlying LOB applications are not really fit for purpose to be the underlying sub-systems for a hybrid API. In this case we have some information held across 2 databases which are years old and clogged full of crappy technical debt which has festered over the years. Creating an API with a strong dependency on these would be like building on quick sand.
At the same time the organisation has a desire at some point (unknown timescale) to transition from the legacy applications to something new but we do not know what that will be yet.
I love these kinds of architecture challenges and it emphasises the point that there isn’t really such a thing as a target architecture because things always change so you need to think of architecture as always in transition and as a journey. If we are going to do something now we should add some thinking about what we might do later to make sure the journey is smooth.
Expected Architecture
Below is a diagram of one of a number of ways you might expect to implement the typical hybrid API architecture using the Microsoft technology stack today. This would be one of the typical candidate architectures for consideration for this pattern in normal circumstances.
The problem with this architecture is mainly the dependency on the LOB systems which mean we inherit some very risky stuff for our API. For example if we suddenly had a large number of users on the API (or even a small number) you could easily see these legacy systems creaking.
Proposed Architecture
What I was considering instead was the idea that if we can define a canonical data definition for the data which we know doesn’t change very often then we can sync the data to the cloud and the API would use that cloud data to drive the API. This means our API would be very robust and scalable. At the same time it also means we take all of the load away from the LOB applications so we do not risk breaking them.
Once the data is in a nice json friendly format in the cloud this means we have distinct layer of separation between the API and underlying LOB applications. For our future transition to replace the LOB applications this means we just need to keep the JSON files up to date to support the API which should be relatively simple to do.
At present I think BizTalk is our best tool for bending the LOB data to the JSON formats as it does dirty LOB integration very well and can be scheduled to run when required. In the future we may or may not use BizTalk to do the sync process, that’s a decision we will make at the time.
API Management to Blob Storage
Following on from my previous post, by using APIM and a well structured data model using the files in blob storage it became very easy to expose the files in blob storage as the API with zero code. We could simply use the url template rewrite features to convert the API proxy friendly url for the client to the the back end Azure Blob Storage url.
The next result is our API would scale massively without too much trouble, have zero code, can use all of the APIM features and give a great way for client applications to search the course library without us worrying about the underlying LOB applications
The below video will demonstrate a quick walk through of this.
[embedded content]
by Gautam | Feb 2, 2017 | BizTalk Community Blogs via Syndication
Azure Application Gateway a Layer-7 HTTP load balancer that provides application-level routing and load balancing services. It distributes traffic requests based upon data found in application layer protocols such as HTTP/HTTPS and also on application specific data such as HTTP headers, cookies, or data within the application message itself, such as the value of a specific parameter.
You basically need to define rules to accept the traffic requests and route them to the appropriate back-end instances.
Application Gateway currently supports the following features:
- Web Application Firewall (WAF)
- Scaleble, highly-available HTTP load balancing solution
- Cookie-based session affinity
- SSL offload for better utilization
- URL-based content routing
- Multi-site routing
- Web socket support
- Health monitoring
- Advance diagnostics
While Azure is responsible for securing the infrastructure and platform that your application runs on, it is your responsibility to secure your application itself. Now Web Application Firewall (WAF) in Azure Application Gateway can provide protection to your web applications against common threats such as SQL injection, cross-site scripting attacks, and session hijacks.
If your organization hosts highly sensitive information, the number-one priority is having a fully-isolated and dedicated environment for only your organization’s applications. Using an App Service Environment, your organization can have security and isolation for your web apps and use a virtual network for control over traffic.
An App Service Environment is a premium service plan option of Azure App Service that provides a fully isolated and dedicated environment. App Service Environments are isolated to run only a single customer’s applications and are always deployed into an Azure Virtual Network. At a high level, an App Service Environment consists of compute resources running in the Azure Hosted Service, Storage, Database, a Virtual Network, and a subnet with the hosted service running in it.
From a single open port, one option to block most traffic would be to use WAF in Application gateway in front of ASE to protect your Web apps.You can also Create a network security group, and assign it to a subnet in your Azure Virtual Network to restrict traffic to the App Service Environment from the WAF only by using the VIP address.
Here you have all the security with a straight forward architecture. Easy to provision, maintain and administer.
The path for request would be: App Gateway (WAF mode) –> ASE
To create this architecture here are the steps involved:
- Create a virtual network (ex: frontend-vnet) for both App Service Environment (ASE) and Application Gateway(AG).
- Create subnet for Application Gateway. Subnet for App Service Environment will be created as a part of ASE provision process.
- Creates an App Service Environment in your virtual network with a private internal load balancer address using Azure Quickstart Template. This step would take up to 2 hours to complete.
- Deploy a test web app – The vnet (frontend-vnet) is not publicly accessible so in order to deploy app, you need to create a Virtual Machine that is living within the same Virtual Network and use that to deploy and access the Web App with its internal IP. Once you have deployed your test web app, you should successfully be able to access it from any VM which is living within same vnet (frontend-vnet).
- Create WAF-enable Application Gateway
- Configure Application Gateway
- Test your web app form public endpoint.
In this blog post I will go through the creation and configuration of Application Gateway in detail.
Create WAF-enabled Application Gateway
In Azure Portal, Go to New—>Networking and select Application Gateway. Provide the information for the basic setting as shown below. Make sure you select WAF tier.
In the settings, make sure to select the same Virtual Network (frontend-vnet) you used to configure ASE earlier and the subnet you created specifically for the Application Gateway. You also need configure the public IP address.
Configure the WAF specific settings.
- Firewall status – This setting turns WAF on or off.
- Firewall mode – This setting determines the actions WAF takes on malicious traffic. If Detection is chosen, traffic is only logged. If Prevention is chosen, traffic is logged and stopped with a 403 Unauthorized.
Review the results and click on OK to create the gateway.
Configure the Application Gateway
Add servers to backend pool – Once the application gateway is created, go to the Backend Pools and select the current backend pool.
Add the IP address of ILB ASE and Save. Now the incoming traffic that enters the application gateway would be routed to the backend address added here.
Configure SSL offload – Application gateway can be configured to terminate the Secure Sockets Layer (SSL) session at the gateway to avoid costly task of decrypting HTTPS traffic off your web servers. Application gateway decrypts the request and sends it to backend server and re-encrypts the response before sending it back to the client.
To configure SSL offload with an application gateway, a certificate (pfx format) is required. This certificate is loaded on the application gateway and used to encrypt and decrypt the traffic sent via SSL.
Add an HTTPS listener – It will look for traffic based on its configuration and helps route the traffic to the backend pools. Click Listeners and click the Add button to add a listener. Fill out the required information for the listener and upload the .pfx certificate.
Create a rule and associate it to the listener – Once listener is created, you need to create a rule to handle the traffic from the listener. Click the Rules of the application gateway, and then click Add. Type in the friendly name for the rule and choose the listener created in the previous step. Choose the appropriate backend pool and http setting and click OK.
Create the custom probe – Custom probes allow you to have a more granular control over the health monitoring. When using custom probes, you can configure the probe interval, the URL and path to test, and how many failed responses to accept before marking the back-end pool instance as unhealthy.
Probes are configured in a two-step process through the portal. The first step is to create the probe. Next you add the probe to the backend http settings of the application gateway. Create a Custom Probe with the Host set as your custom Web App domain, for example sample-app.com as shown below.
Add probe to the gateway – Go to the HTTP settings, and make sure that the setting has Custom Probes turned on and select the probe you just created. Otherwise, the Application Gateway will try to go to the IP of the App Service Environment without passing a Host header, which won’t work and will throw the probe into an Unhealthy state resulting in the 502 Gateway Proxy error.
Testing
There are couple of ways to do the testing. First you can use ModHeader Chrome extension to open the public IP address/hostname of the Application Gateway in the browser. You need to pass in the Custom Domain you configured on the Web App as a Host Header and the website should come up. Refer Sabbour blog post for further detail.
The other way is to add hostname (sample-app.com) to Custom Domains in the setting of app deployed in ASE as shown below.
You need to add an entry for your host in Hosts file on your local machine. The path would be c:WindowsSystem32Driversetchosts.
Now if you go to https://sample-app.com it should open up the sample web app as shown below.
Logging and troubleshooting
Application Gateway provides following capabilities to monitor resources.
Backend health – Application gateway provides the capability to monitor the health of individual members of the backend pools through the portal, PowerShell, and CLI.
Logging – There are different types of logs in Azure to manage and troubleshoot application gateways such as performance, firewall and access logs.
Here is a sample firewall log.
There are three different options to choose for storing your logs
- Storage Account
- Event Hubs
- Log Analytics
Metrics – Application gateway currently has one metric. This metric measures the throughput of the application gateway in Bytes per second.
You can also set alert rule for application gateway based on metrics on a resource.
For example, an alert can email an administrator if the throughput of the application gateway is above, below or at a threshold for a specified period of time.
Summary
To summarize, we explored the option to protect your web applications against common threats such as SQL injection, cross-site scripting attacks, and session hijacks using Azure Application Gateway. We ‘ve hosted a Web App securely in an App Service Environment. This Web App isn’t publicly accessible as it is sitting in a subnet inside a Virtual Network and it isn’t exposed to the internet. The only way to access the site is through a Web Application Firewall enabled Application Gateway.
by Sandro Pereira | Feb 2, 2017 | BizTalk Community Blogs via Syndication
This is a collection of 5 different image formats of the new Unofficial BizTalk Server 2016 logotype (check the official logo here), three of them are available in vector format that will allow you to use and resize without losing quality:
- BizTalkServer2016-linhas.ai
- BizTalkServer2016-linhas.eps
- BizTalkServer2016-linhas.pdf
- BizTalkServer2016-linhas-01.jpg
- BizTalkServer2016-linhas-01.png
that can be used to customize a banner for your blog, an article, making flyers, stickers, brochure or rollups for BizTalk events.
Again, this is not the official logo. In the official logo, Microsoft decided to drop the fancy Server icon from the logo and the version identification, now it is a simple generic logo with just Text that will be consistent in this and further versions of BizTalk Server. But people sometimes prefer to use the “old” format just because it is easier to visual specify the version of BizTalk Server… for that reason only there you have!
Thanks to António Lopes (UX/UI DESIGNER at DevScope) for helping me creating these resources.
(Unofficial) BizTalk Server 2016 logo in vector format (2.4 MB)
Microsoft | TechNet Gallery
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
