With Integration Monday reaching a wider audience, we thought it would make sense to write blog posts on the events. We will keep the post very simple with brief snippets from the session and provide links to code samples/demos (if available from the presenter) which will be really helpful for our blog lovers and the community.
In this blog, let’s take a quick recap of the session on “BizTalk ALM” by Toon Vanhoutte from Codit.
Toon Vanhoutte is an Integration Architect with over 9 years of experience in the Microsoft Integration space. Toon is a Microsoft Certified Trainer and an AS4 OASIS Committee Member. AS4 is the latest B2B messaging protocol and is a successor of the existing AS2 messaging protocol.
The scope of the session was towards the technical aspects of BizTalk Application Lifecycle Management (ALM) and Continuous Integration concepts. Throughout the session, Toon made use of Community available software such as BizTalk Map Test Framework, BizTalk Deployment Framework, Winterdom Pipeline & Schema Testing, BizTalk ALM Guidance, and TransMock Integration Testing Framework.
Toon started off by quoting the “Pain Points” that we often hear from the developers and IT Managers when it comes to Application Development Lifecycle. Say, for instance, a developer being cautious and taking multiple back-ups of the pipeline component before editing it since it’s been used in multiple flows, or, when the developer forgets to update the context promoted properties while regenerating the schema file; such issues can be easily corrected in the ALM Cycle with the help of Unit Testing and Integration Testing, if they are properly in place.
The session dived deeper into Continuous Integration concepts where Toon explained the concepts of Continuous Integration (Code Repository, Daily Check-In, Build Automation, Test Automation, and Deploy Automation), their advantages and disadvantages. The key point to note is the “Return On Investment” Factor and Toon stresses the fact that organizations need to prepare well in advance how much they need to spend on Continuous Integration and Application Lifecycle Management. For every project, there has to be a minimum level of Continuous Integration in place to avoid the “pain points” mentioned before – a basic code repository, Automatic Build, and Automatic Unit Testing.
Toon considered a real time scenario where an ERP system (a SQL database) communicates with an invoicing system and the invoices are stored as flat files on the disks. There was also an orchestration calling an external web service with two-way port as part of the scenario. The rest of the session mainly revolved around this scenario with lots of hands-on demos on specific concepts like Unit Testing, Automated Build, Automatic Deployment, and Integration Testing (using TransMock Framework)
As a developer, Unit Testing is a key to know whether the piece of code you’ve developed works effectively or not. Unit testing can be performed directly on the code base, or you have the option to deploy a specific BizTalk Application and run the tests on them. The first approach (to run the unit testing directly on the code base) would be very effective on .Net Libraries, Schemas, Maps, Pipelines, and Pipeline Components and it generally improves your productivity. For example, consider testing the pipeline component. You must first add the pipeline component to the appropriate folder, which may be locked by the BizTalk Host Instance. You are forced to stop the host instance, add the pipeline component, and then restart the host instance. This is a time-consuming process, and if the entire process can be mocked as a part of the unit tests, it automatically improves your productivity.
We recommend you to watch the session in detail where Toon shows various demos on the following –
[list type=unordered extra=] [list_item]Unit testing of a flat file schema (using Winterdom schema tester)[/list_item] [list_item]Unit testing of pipelines and pipeline components (using Winterdom PipelineTester)[/list_item] [/list]
In the demo, Toon uses the BizTalk Development Framework to deploy the solution. He shows the detailed steps to deploy the BizTalk solution automatically. Toon also shows how you can customize the build workflow to apply versioning (using BizTalk ALM Codeplex Powershell Scripts) before deploying the BizTalk solution (automatically).
There may be situations when as a developer (in a development environment), you will not have access t0 the backend systems, (in our case the ERP system). Therefore, it may not be practically possible to perform an integration testing between the invoicing application and ERP application. This is where the concept of “TransMock” comes into effect. TransMock is a (new) framework that allows you to easily test the functionality of a BizTalk Server integration on a developer box or a build server without the need of complex setups of system test instances or respective stubs and mock-ups. (Courtesy – http://bizzitalk.blogspot.be/). In our case, all we can do is simply “mock” the ERP setup on the development set up and perform the integration testing between the two systems.
Transmock can be found on Codeplex, and basically consists of two components – the Mockifier and a component that allows for seamless integration with BizUnit by adopting its API and thereby confronting to its test authoring and execution models. In addition to this, Mock Adapter is an essential aspect of the framework. The combination of TransMock specific BizUnit steps and the Mock adapter executing in the respective receive locations and send port makes it possible to carry out tests of BizTalk server integrations in a mock-like fashion. Watch the video to see how you can set up TransMock and perform Integration Testing of your systems.
We believe this will be a very useful video for BizTalk Developers to increase your productivity and perform better unit/integration testing of your applications. This article is just to give you a glimpse of what’s been covered in the session. We recommend you to watch the video to understand all the concepts better.
Back to Top