by Gautam | Aug 6, 2018 | 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!
Feedback
Hope this would be helpful. Please feel free to reach out to me with your feedback and questions.
by Bill Chesnut | Aug 5, 2018 | BizTalk Community Blogs via Syndication
By Bill Chesnut
This is the second post in a multi part series on the features of Azure API Management.
As with the previous post where I demonstrated publishing a SOAP Services with pass-through, this time I am going to demonstrate publishing the same SOAP Service as REST, using the SOAP to REST feature of API Management, I consider this feature very important to APIM, in the past many of my clients have built intermediate services using either BizTalk or .Net.
For this blog post I am going to demonstrate how you publish a BizTalk SOAP service as REST in APIM. With APIM you can publish SOAP services by importing the WSDL (this can be either via the URL or by uploading the WSDL file), In APIM Click the “API” menu item on the left, then Click “WSDL”
In this demonstration I am going to use an uploaded file, this is the WSDL from a BizTalk orchestration exposed as a WCF Request/Response Service, it only has a single operation ‘submit”. I am using an uploaded file because the BizTalk server is hosted in an Azure Virtual Machine and I have changed the URL to reflect the DNS name of the Virtual Machine. I could have also changed the name in APIM after the WSDL was imported. Select “SOAP to REST” and configure as shown and click “Create”
Once the WSDL import is complete, we can now see the API and it’s operations, now let click settings to look at the API settings, this is where we can change the URL to the BizTalk Server hosting our SOAP Service. Click the “submit” operation, then click the “policy editor”
Now look at the policy that does the transformation from REST/JSON to SOAP/XML.
Inbound
Outbound
Now lets click the “Test” menu, this is where we can test our API Operation, before we release them to our consumers
APIM fills in all the details to test the API, notice that the payload for the API is JSON, this is because we chose SOAP to REST, SOAP services are XML based, but the above policy we looked at does the conversion from JSON to XML. Click “try it”
You can now see the results of our call to the BizTalk hosted SOAP Service, the results are in JSON again the policy is doing the conversion, now lets click the “trace” tab, this will give us everything that has taken place in APIM as part of our call to the BizTalk SOAP service. You can notice that the policy has set the SOAPAction and converted the JSON body to XML
The Policy for the SOAP to REST feature is using Liquid Template Language to do the JSON to XML and XML to JSON transforms, these templates can be use to transform from JSON to XML, XML to JSON, XML to XML and JSON to JSON, this allow not only the scenario for SOAP to REST, but the ability to manipulate both inbound and outbound payload for maximum flexibility.
Hopefully this has given you a quick demonstration on how to expose your SOAP Services as REST with APIM.
Cross Posted on http://www.sixpivot.com.au
by Senthil Palanisamy | Aug 2, 2018 | BizTalk Community Blogs via Syndication
Introduction
Most of users prefer to install BizTalk360 in a standalone sever. Importantly, this approach does not overload the BizTalk environment or the BizTalk360 instance. Quite often, BizTalk360 database is configured in the same SQL Server instance as where BizTalk databases resides. In this case, configuring database in a separate SQL Server Instance for better performance and disk usage. Considering this fact, customers are acquiring a dedicated SQL Server for the BizTalk360 database. Meanwhile, few customers are using SQL Server Express edition, when they don’t prefer to buy a separate license for SQL Server. This article covers things that need to be considered when BizTalk360 with SQL Server Express Edition.
Customer Scenario
BizTalk360 is installed on a standalone server with all components, which are:
- The database
- The web portal
- The monitoring
- The analytics services
The customer has installed SQL Server 2017 Express edition
SQL Server Express Edition
Let us see features and limitations of SQL Server Express edition.
Features
- There is no requirement of license for using it, as it is free for distribution
- It is an easy to use version, designed for building simple data driven applications
- Applications develop faster through the deep integration with Visual Web Developer, Visual Studio, and so on
- Easy to create and share reports that answer complex questions through basic reporting services
- Provides backup and restore functionality and compatibility with all its versions
Limitations
- SQL Server Express can be installed on a server with many CPUs. But, it can use only one CPU at a time and 4GB database size limit was there for SQL2005/2008 but after 2008R2 it has been increased to up to 10GB for each database. For this limit, only the size of the Data file is considered. The size of the Log file is not relevant
- Can use a maximum of 1GB memory for temporarily storing the data while it is being transferred from one place to the other
- The performance analysis tool, Profiles, is not included with the SQL Server Express edition
- The functionality to create and attach a schedule to a job (Job Scheduler) is not available with the express edition
- You cannot import or export the data with the SQL server express as this feature is also not available
BizTalk360 as Lightweight
Under this circumstance, user must take care few considerations in BizTalk360 to keep the size of database within the value supported by SQL Express Edition. For better performance of data processing, make sure you keep the database as light as possible.
The following configuration will help to maintain BizTalk360 database as lightweight:
- Event Log
- Analytics
- Data Purging
Event Log
In a BizTalk environment it’s important to monitor the Event Log to avoid any activities blocked at the back-end. A BizTalk Administrator’s main job is to keep BizTalk System Resources, Disk Usage and Database processes 100% healthy!
BizTalk360 collects Event Log data based on configured Event Logs and Event Log Sources. With this collected data, the BizTalk360 Monitoring service will send notifications based on configuration (Threshold and Data Monitoring). From the Operations section, Event Log data access functionality is also available with all kind of filtering capabilities. In BizTalk Reporting Analytics, the Event Log widget is populating the report with “Top 10” Event Log sources.
Event Log data collection will need more space based on the configured number of sources and the number of physical BizTalk Servers and SQL Servers in an environment. We can see the possibility to reduce the amount of event log data collection by:
- Configure just the important Event Log type and sources you want to monitor
- Enable Event Log data collection only at the physical server level (BizTalk/SQL) for which Event Log monitoring is important
Analytics
In a BizTalk production environment most of the users are using the BizTalk360 Analytics capabilities. The ‘Analytics’ section has the Performance Analyser functionality, the Messaging Patterns and the Throttling Analyser. The BizTalk360 services are also collecting data to generate the graphical widgets which are shown in multiple dashboards. Both Throttling and Performance data are collected every 15 secs. In a complex BizTalk environment data collection is at considerable size.
BizTalk Artifacts tracking is enabled at port level and at pipeline level. BizTalk360 uses its Analytics service to determine Message Patterns are by querying tracking data which is collected from the BizTalkDTADb. Similarly, tracking data is used to visualize messaging performance by port and by pipeline.
The Analytics service is responsible for collecting the Throttling Performance Counter data from all the BizTalk servers in the environment. The BizTalk360 Throttling Analyser helps to simplify the complexity in understanding BizTalk throttling mechanism and provide a simple dashboard view.
Users can observe the ways to optimize the data collection;
- Disable unnecessary tracking (Port and Pipeline). When possible, try to limit to Event tracking and prevent using Message body and context tracking, it will also boost performance of the BizTalk Tracking database
- Configure requirement performance counters in an environment to boost the data collection
To be able to get a good overview of all the Tracking settings within your BizTalk environment and to configure these settings in one consolidated screen, you can use the Advanced Tracking Manager.
Data Purging
BizTalk360 comes out of the box with the ability to set purging duration. The background Monitoring service has the capability to purge older data automatically after a specified period. Data purging is configurable for different activities in which can be found under BizTalk360 Settings > Data Purging. Through this feature, you can control the size of data of the BizTalk360 database.
Compromising Performance and Storage?
We have seen about the performance and the size of data with several features in BizTalk360. Using SQL Express edition with 4 CPU Cores, 1410 MB of buffer pool size and storage of 10 GB in a BizTalk Production environment is critical. A BizTalk/Database administrator must monitor the size of the database by setting purging policies to a minimum period for data persistence.
Conclusion
Consider using SQL Express edition with BizTalk360 based on case by case as we discussed.
- Using SQL Express Edition in a critical production environment is not suggested as it compromises performance and data storage. For those BizTalk environments with more than one BizTalk servers, we advise to use a higher edition of SQL Server
- In Non-Production environments install different BizTalk360 instances by considering
- Enable important Event Log source to data collection.
- Another key point is configure single BizTalk environment in a BizTalk360 Instance.
- Periodically check the size of database and optimize the collected data.
Author: Senthil Palanisamy
Senthil Palanisamy is the Technical Lead at BizTalk360 having 12 years of experience in Microsoft Technologies. Worked various products across domains like Health Care, Energy and Retail. View all posts by Senthil Palanisamy
