UppercuT - ConfigBuilder
ConfigBuilder will build a configuration file per environment so you no longer have to maintain a bunch of configuration files.
In any project you have app.config (or web.config) files. You just create a .template file next to it. The web.config has a file next to it named web.config.template. What do you name the app.config template files? You have to name the file based on what app.config becomes when visual studio builds the application.
1. First you need to find out what the application configuration is going to be called when it is built. This is typically the dll or exe name with .config at the end. In the example below it is AutoTest.Console.exe.config.
2. Then in your solution find the App.config file. Right click and select [Copy].
3. Paste it back into the project. Right click on the project and select [Paste].
4. Rename the file to the same as you found the output file to be, but with .template after it. In our case this would be AutoTest.Console.exe.config.template.
5. Click {Yes} on the warning by Visual Studio.
6. Right click on the new template file and select [Properties].
7. In the properties dialog and make the following edits:
a. [Build Action] should be Content.
b. [Copy to Output Directory] should be Copy always or Copy if newer.
8. Now open the *.template file. Make edits to replace values with values that change in each environment. You do this by inserting a reference to a variable, “${variableName}”. In the example below, I am replacing my log4Net logging level with a variable I can change across environments. This is so I can have DEBUG on in DEV, but possibly as high as WARNING or ERROR in PROD.
a. You may have noticed that Windsor Castle Service locators look identical. Leave those as they are.
9. Follow the above steps for every configuration file you might have (including other xml files).
10. In the Settings folder, create ENVIRONMENT.settings files.
11. In each file there is a property defined to replace properties referenced in the *.template file(s).
12. If you use Windsor Castle Service Locators, they are fine as they are. There is nothing that needs to be done with them.
13. When you run build.bat the next time, you are going to see messages like this. One per environment and each template file.
14. In the code_drop folder, you notice that now you have an environment.files folder.
15. In the environment.files folder, the number of files here is determined by the number of ENVIRONMENT.settings files times the number of *.template files.
Setup and installation of the PeerEval system
Setup and installation of the PeerEval system should be straightforward to someone who is familiar with the Microsoft technologies involved. This includes IIS, MS SQL Server, and Windows Server administration.
1.1. Web Server Setup (IIS)
A virtual directory needs to be created to point to the Web folder, where the web pages reside. This virtual directory needs to be configured to host an ASP.NET 2.0 application. The anonymous web user (IUSR_COMPUTERNAME) needs to be given read access to the web folder. The ASP.NET user (ASPNET) needs read access to Web, Web/bin, and it needs read/write/modify access to the web/log folder. Note that logging functionality is not fully supported by log4net under the ASP.NET 2.0 model, but does not affect performance of the system in any way.
1.2. Database Setup
To set up the database, a new database needs to first be created in the Microsoft database manager. Then the file data/db.sql may be run to create the tables. Note that the two views at the bottom of the script must be created separately. Also, “mixed mode” authentication should be used for database access. DO NOT use the ‘sa’ user to as the Peer Eval system’s database access. This is an extreme security risk in any application. Instead, create a new database user specifically for the Peer Eval system, and take note of the user name and password to use in the connection string. The new database user needs read/write/create/update access to the database.
1.3. Settings Files
Each library has a corresponding setting file, with the same name as the library, i.e. PeerEval.Web.dll has a settings file named PeerEval.Web.xml. The settings file must also reside in the same directory as the library (typically web/bin). Note that these files must be valid XML.
1.3.1 PeerEval.Util.xml
This file defines the database connection string, and the data provider class name.
1.3.2 PeerEval.Business.xml
This file defines the IAuthManager class name.
1.3.3 PeerEval.Web.xml
This file defines whether debug mode is turned on. If it is, error messages will include a full exception stack trace, viewable to the end user.
Posted in: Software Software Programming| Tags: Database XML IIS PeerEval system PeerEval.Business.xml PeerEval.Util.xml PeerEval.Web.xml Setup Web Server SetupTechnical Parallels between SeeBeyond and Biztalk
Having discussed migration approaches, we want to highlight another challenge/dilemma that can come in the way of getting a quick start on the migration effort. The challenge is ability of a BizTalk trained team to be able to quickly understand the parallels between SeeBeyond and BizTalk.
Given this challenge and dilemma, we decided to dedicate a section to discussing these parallels and draw some analogies between the concepts, features, technologies and artifacts of the BizTalk and SeeBeyond platforms.
The best way to learn is by example. For the BizTalk architect or developer attempting a migration project - the first look into the SeeBeyond world is confusing and ambiguous – because the familiar concepts and artifacts they are familiar with in BizTalk are missing or fused with another feature. For some there are simply no parallels at all. There is little or no documentation available in this area on the internet and one has to rely on assistance from experts.
Please note that many parallels are mostly loose analogies to help the BizTalk developer gain a newcomer’s familiarity with SeeBeyond. Since the architecture of both platforms is different, drawing parallels between both is a hazardous task, fraught with shoe-horning and over-simplification. We have attempted it nevertheless - on the grounds of giving the migration team a first look / toehold into the world of SeeBeyond and dispel some of the fog surrounding it. Caution is advised against literal interpretation of these parallels – and no technical implementation based on it is recommended. A deeper and more thorough understanding of SeeBeyond Technical Architecture and concepts is advised before the migration project is undertaken.
In order to do the parallels justice, it is perhaps advisable to discuss what are the key components that make up the SeeBeyond suite and how they tie together
Posted in: Software Software Programming| Tags: Microsoft WCF BizTalk BizTalk Migration BizTalk Server EAI integration solutions Microsoft Biztalk SeeBeyond Technical ParallelsTechnical lessons in BizTalk Migration
1. Although SeeBeyond Collaborations can be translated to BizTalk Orchestrations, it makes better sense to separate an implementation into Orchestrations for business processes, Maps for data transformation, Business Rule policies for business logic, and Pipelines for low level message pre-processing. In a SeeBeyond implementation, the Collaboration is the main executive module where most logic resides - and all these sub-tasks are mixed together creating a delirious “code cocktail” we have witnessed first-hand. In BizTalk such collaboration can be cleanly split into functional modules which are easier to maintain.
2. Data conversion. Type system mismatch between Java and .Net, date and time formatting can be sources of subtle errors. For example, in Java the default DateTime string formatting is different from neutral culture formatted DataTime string in the .NET Common Type System. SeeBeyond code compare dates as strings which is culture specific in .Net, so it’s better to switch to a DateTime object.
3. Message size. In SeeBeyond messages are binary structures and strings. But all flat file and native messages entering BizTalk are converted into XML – blowing up their size 3 to 5, even 10 times! When these are mapped they are held in memory as is the transformed message – which is equally large perhaps. This can easily lead to performance problems due to memory pressure. One should pay close attention to the message size. Since messages in BizTalk are immutable developers may create duplicates in the orchestrations which will add to the memory overhead. Instead the BizTalk developer should chunk up the message into smaller (physical) sizes – as BizTalk is highly parallel and is best optimized for processing a high throughput of light-weight or medium-weight messages with remarkable speed – but the reverse (heavy messages and low throughput) is not true.
4. SeeBeyond’s data structures map pretty well to .Net typed DataSet. This fact can be used when converting component logic from Java to .Net. Entire structures can be mapped to a typed dataset which makes case for straightforward code conversion. There is a difference thoough – nullable types. .NET DataSet supports DbNull and this should be taken in account.
5. Centralized logging and tracing is critical in this type of mission. Microsoft Enterprise Logging Block or Log4Net library can help to tackle this task.
6. Sometimes it makes far more sense to engineer the logic in .NET components than BizTalk. Just because it’s a migration exercise does not mean BizTalk is a natural choice. A .NET library with a BizTalk wrapper can do the trick in many cases – do try to think out of the box when evaluating design.
7. Proper encoding should be used for data both in xml as well as in flat file formats. If this is not taken care of, it may result in output data mismatch and can lead to multiple test cycles and rework.
8. Automated test scripts also play a major role in making things easier since you must be prepared for many cycles of verification and overload testing.
Posted in: Software| Tags: Microsoft WCF BizTalk BizTalk Migration BizTalk Server EAI integration solutions Project ManagementDiscovery and Development Strategy of BizTalk Migration
With any migration approach, discovery of SeeBeyond code and artifacts is necessary due to the invaluable wealth of information there which has survived due its robustness or been refined to its current state. Not to use it would be an enormous waste. Although a huge amount of it is redundant in BizTalk due to the pre-built infrastructure (ports, adapters, configuration) you can mine a lot of it outright – some of it a simple cut and paste – such as database queries. Hence knowledge of SeeBeyond is inescapable.
To delve into SeeBeyond or to have a meaningful exchange with the SeeBeyond analyst, it would benefit the BizTalk professional greatly if could gain a first look inside SeeBeyond with the concepts and mental models he is already familiar with. Getting sufficient time from the harried, expensive and stretched thin SeeBeyond analyst is likely not going to be easy to come by, so the problem gets worse.
We have painstaking compiled a reference section to help with this comprehension – you will find this in the Appendix A of this paper.
Once the migration is complete, it is necessary to ensure that the new destination data is semantically equivalent to the original destination data (that has been processed with the SeeBeyond implementation). For this to be so, the results of all operations on the new Biztalk solutions must be identical to those on the old SeeBeyond solutions. There is no better way to gain such assurance than to exhaustively perform the same operations on both solutions and to compare the results. We recommend a Cross-Talk approach for verification testing.
In the Cross-Talk QA approach, the data source is flipped from SeeBeyond to BizTalk receivers and the results compared. When verified with a credible set of test queries, a high degree of assurance can be obtained from this approach that the new data store is semantically equivalent to the old one.
Posted in: Software| Tags: Microsoft WCF B2B BizTalk BizTalk Server EAI flagship integration solutions Migrating Windows Communication FrameworkReArchitecture in BizTalk Migration
This rearchitecture approach is ideal in circumstances where the original implementation is sub-optimal (has performance issues or has been overtaken by new developments) or was developed in multiple layers laid on top over time of one another without an inherent design.
Even systems with well-defined architectures are prone to structural erosion. The relentless onslaught of changing requirements that any successful system attracts can gradually undermine its structure. Systems that were once tidy become overgrown as piecemeal growth gradually allows elements of the system to sprawl in an uncontrolled feature-creep. If such sprawl continues unabated, the structure of the system can become so badly compromised that it must be abandoned. The only way to sustain this system is by patches, and over time layers develop, until no shred of any original architecture or pattern remains.
Such systems are usually very difficult to maintain, document and perform poorly, making them good candidates for complete re-writes. In this case rearchitecture in a new system (BizTalk) from the ground up makes most sense as looking under the hood will confuse and provide no net benefit. There will also be many subtle, and not so subtle, differences between the old and new platforms and these make manual translation very difficult. A developer can quickly get led astray by the many subtle differences and become unproductive due to the overhead of constantly switching back and forth between old and new tools and platforms.
The newly designed system will accommodate new features, use the latest standards, and follow best practices for component reuse. The lessons from the previous implementation and hindsight will always be available, making the second generation solution a robust and optimized implementation.
Here are some tips for a rearchitecture approach
· Make use of accepted standards like HL7, HIPAA, RosettaNet, cXML, GS1, etc where applicable
· Loose coupling enabling other applications to be plugged in later
· Common components should be separated out into frameworks for reusability
· Avoid using custom connectors as these are difficult to develop and maintain
· Insist on automation of testing process to check for regression
· Run a performance lab and overload tests to make sure the application scales
· Ask for load balancing and fail over strategies for deployment
Posted in: Software Software Programming| Tags: Microsoft WCF B2B BizTalk BizTalk Server EAI flagship integration solutions Migrating Windows Communication FrameworkWhy migrate from SeeBeyond to BizTalk?
Migrating from a large EAI platform to another is always a tough decision and cannot be made in vacuum. Whatever EAI platform an enterprise has in place forms the backbone of their enterprise when it comes to their data communication needs. The EAI platform is what one would analogously consider the “plumbing” of a house. If the plumbing fails, the house is unlivable and alternate arrangements have to be made.
Given the business criticality of an EAI solution, it is essential for an enterprise to choose a tool that is scalable, robust, extensible and most importantly maintainable. Typically these are qualities one would look in any software tool, but nowhere are they more important then in an EAI tool.
Historically, the problem with EAI tools in the enterprise space has been their lack of ability to continue to evolve to the new standards and advancements in technology and also the ability to scale with the growing demands of business. The tools that did manage to provide patches to the tools for such advances were usually “kludgey” solutions that were not truly integrated with the tool. Given these challenges that are bound to occur with any EAI tool now or in the future, it is prudent to move with a tool that is supported by a financially stable company which will be there for the long haul and has the deep pockets to support the advancements in technology. The reasons discussed about inability to evolve and scale has plagued the EAI industry until now because typically all EAI vendors have been small companies with their own agendas dictated more by wall street than the needs of their customers and as a result virtually all the key players have either almost vanished (Vitria) or have been acquired by larger corporations to fill a niche in their overall solution portfolio (SeeBeyond being purchased by Sun is a prime example) when the focus of the company may not be EAI.
Biztalk is one of the few tools that has grown internally within Microsoft and has been nurtured over the past few years for it to mature and achieve enterprise status. It is supported by the most financially stable software corporation on the planet and has the deep pockets and resources to keep evolving BizTalk to the ever changing needs.
Regardless of what tool an enterprise may be utilizing currently, chances are the enterprise will hit a point where the tool is unable to evolve or scale as needed and the sooner an enterprise makes a decision to move with an industry leader, the safer its investment in time, resources and money will be.
Having discussed some benefits of moving to BizTalk as a tool for choice, here are some points to consider why it is beneficial to move away from other EAI tools such as SeeBeyond.
· Expensive to maintain and increases TCO (Total Cost of Ownership)
· Is no longer a market leader in EAI tools and will eventually phase out and disappear where components are cannibalized and utilized in the J2EE frameworks from Sun
· Product is not backwards compatible with older versions
· Lack of backward and forwards compatibility requires constant re-tooling of team
· Upgrade in SeeBeyond is resource intensive and time consuming
· Takes longer to make changes to functionality
Posted in: Software Software Programming| Tags: Microsoft WCF B2B BizTalk BizTalk Server EAI flagship integration solutions Migrating Windows Communication FrameworkCons of SeeBeyond to BizTalk Migration
· Cannot be decoupled from the proprietary data storage layer – Microsoft SQL Server. This means a deployment must also acquire SQL Server licenses even though it may be using a different DB solution.
· Debugging the main business process logic - orchestrations – is non-standard, circuitous, and discouragingly complex (stepping through code debugging involves understanding the XLang library) – although nearly every error message has profuse help available from the online community.
· BizTalk development involves little coding but a lot of configuration. Configuration errors are cryptic, difficult to trap, trace or debug – resulting in once again defaulting to help from the community rather than the software itself
· UML compliance for modeling the business processes (Orchestrations) is missing
· Recovery of failed messages is manual and not automated
· Monitoring is dependent on additional software like Microsoft Operations Manager and is not available out of the box
· Runs only on Windows and not on other server operating systems like UNIX flavors. Although the Microsoft server platform is the fastest growing server system, this is still limiting to its adoption base for non-Windows deployments. The product is also reliant on core OS services like security, scale out and authentication.
Posted in: Software Software Programming| Tags: Microsoft WCF B2B BizTalk BizTalk Server BizTalk Server 2006 EAI flagship integration solutions Windows Communication Framework