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 SetupOverview of SeeBeyond for the BizTalk professional
The SeeBeyond e*Gate integrator is the core of the platform. The e*Gate Integrator enables the flow of information by providing connectivity to applications and datastores across a network. You can loosely think of them as a BizTalk 2006 Application than encompasses all the different artifacts. e*Gate is based on a distributed architecture with an open design that deploys load balancing options. e*Gate processes events according to user-defined business logic and integrates business processes between applications, ensuring end-to-end data flow into back-office systems.
The record structures of messages (called Events in SeeBeyond) that are transferred to and fro are called an "Object Type Definition" (OTD). OTDs are created from source types and can represent any record type, e.g. XML, BAPI, Flat File, Relational row, WSDL, etc. You can think of them as the canonical type definition used by the platform - or schemas in the BizTalk World. The OTD is a Java class. It does all the marshalling/unmarshalling to these various formats.
e*Way are key components of an e*Gate and provide application connectivity and data processing such as business collaborations, transformation logic, and publish/subscribe. They comprise of an executable and a configuration file. You can think of e*Ways as a combination of adapters and ports and their binding information. e*Way connections are analogous to BizTalk ports.
e*Ways have “External Slice” components which is analogous to the communications adapter and the “Work Slice” which can be thought of as an application adapter and some business logic.
Both BizTalk and SeeBeyond support wide accepted standards like XML, XSD, WDSL, SOAP, BPEL4WS and are geared towards messaging and loosely coupled integration. While the integration goals are the same, SeeBeyond has taken a different architectural approach than BizTalk. For example, SeeBeyond does not have a central MessageBox where all messages are delivered and which acts as the subscription engine (although it does have smaller and more numerous Intelligent Queues). SeeBeyond does not insist on XML conversion of Flat File messages (through a pre-processing disassembler).
SeeBeyond eBusiness Integration Suite
The SeeBeyond eBusiness Integration Suite includes the following components and sub-components:
· e*Gate Integrator:
· e*Way Intelligent Adapters
· IQ Intelligent Queues
· Business Object Brokers (BOBs)
· e*Insight Business Process Manager
· e*Xchange Partner Manager
· eSecurity Manager
· e*Index Global Identifier
A one to one comparison of artifacts will probably of much greater help:
| Architectural Parallels between BizTalk and SeeBeyond | |
| BizTalk | SeeBeyond |
| Messaging / routing | Collaboration (data routing) |
| Schema | Structure |
| BizTalk NT Service | E*Gate Registry Service |
| Host Instances | Participating hosts in a Control Broker |
| BizTalk Host | Registry Host |
| BizTalk Administration Console | E*Gate Enterprise Manager GUI |
| Group Hub / Health and Activity Tracking | E*Gate Monitor GUI |
| MessageBox | IQ (Intelligent Queue) datastore – different from MessageBox and is a very loose parallel |
| Immutablity of messages | Events are mutable even inside a IQ |
| Adapter | E*Way |
| Send and Receive Ports | E*Way Connections |
| BOB (Internal e*Gate component used for load balancing) | |
| BizTalk Application | E*Gate |
| Binding file (very loose analogy) | Schema (The parameters and relationships between e*Gate components) |
| Orchestrations | E*Insight BPM (Business Process Manager) |
| Pipelines | (no equivalent) No distict pre-processor artifact, although pre-processing can be impleted in code |
| Visual Studio IDE | SeeBeyond uses its own IDE unlike BizTalk which uses the common .NET IDE Visual Studio. Although SeeBeyond can be coded in J2EE, it does not provide Developer Tools that can be installed as plug-ins for standard IDEs like the Eclipse, Jbuilder, Java Studio Creator, etc. |
| Pub/sub managed by MessageAgent from the MessageBox | Events are published by Collaboration. The Subscription is by the EventType and the Publisher. |
| Business Rules / Policies | Property file – can be changed at runtime. Rules xan also be in the database |
| (no equivalent) – although Group Hub can add more MessageBoxes | IQ Manager controls IQs |
| Content Based Routing | Eventy Types / Collaboration Rules |
| Trading Partner Management | e*Xchange Partner Manager |
| Implemented in .NET Security infrastructure, PKI certificates | eSecurity Manager |
| Business Activity Services | e*Index Global Identifier (e*Index) |
| No direct analogy – implemented in BizTalk Group / Clustering | Business Object Broker (BOB) |
| BTS Management Database | e*Gate Registry |
| Port | E*Way Connnection |
Technical 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 ParallelsMigration Challenges in BizTalk Migration
Integration migration projects are humbling in their complexity and over-whelmingly communication-intensive. You are more likely to run into communication, management and operational challenges which can conspire to defeat your march than any serious technical challenges. An adaptive, agile approach where assumptions are questioned daily and where close anticipation and planning discipline is instilled has a greater chance of success.
Here are pointers and advice about the challenges of an EAI migration project – right from the trenches.
Project Management lessons
1. First, if the “Replicating Behavior” migration approach is chosen, a pilot implementation of an interface would be beneficial. This allows learning a lot about the application scope, get the “big picture”, peek into many technical details and eccentricities early, and foresee upcoming challenges – not to mention planning ahead for infrastructure and performance. This Proof Of Concept is not required to be fully functional and can contain only limited amount of artifacts but should a variety of processes, workflows, operations, adapters etc. allowing to sound out different eccentricities.
2. In all large scale migration projects, it is very important to recreate the environment early. Solution partitioning, project structure, build, server topology, packaging and deployment guidelines should not be left for the last – we cannot overemphasize this. A controlled environment where SeeBeyond and BizTalk application can be run in isolation on the control data set. This is critical as there’s no other means to validate migration quality in this approach except to compare output for the known input. It takes considerable amount of discipline to stick to this plan as features get discovered, complexity grows and the team is crushed under this load – but it is important that this stays in focus as an early deliverable, not late one.
3. Early and continuous integration of the processes along with testing mentioned in 3) above helps to discover problems early and take mitigation actions. This is a key assumption that bedevils many teams who assume so-called isolated systems will not impact each other when run together on the same application server. Make sure to get the latest version of the shared code to avoid unpleasant surprises.
4. Some BizTalk features must be evaluated carefully before applying in implementation. There might be critical limitations that would slow down or even halt migration. For example, the Oracle DB adapter for BizTalk cannot return results of the joins from multiple tables. So, if you require this kind of result set then it’s time to turn back to the more flexible ADO.NET and bid goodbye to a code-free approach. Native SQL schema can be used instead of adapter generated schemas to generalize data access out of orchestrations and make them cleaner and easier to understand and maintain. When creating data access intensive orchestrations it often makes sense to consider delegating Oracle adapter task to a .Net component to get rid of large amount of transient messages and reduce performance overhead.
5. Do a careful analysis of the current code base before committing any timelines or budget. Do not assume the solution you are inheriting is either perfect or well-architected. We have found messy implementations where the management is delegated to UNIX/WMI scripts instead of being controlled from the GUI/e-Ways/Collaboration rules, resulting in business logic being distributed over areas not conducive to maintenance or good practice. When these problems are compounded by lack of documentation, then you need to increase project times by a significant amount to accommodate the pain and increased efforts of first collating logic in the code base into a sensible picture before the analysis and design can even begin.
Posted in: Software Programming| Tags: Microsoft WCF Challenge 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