Pro BizTalk 2006 phần 2 doc

Feature 3: Update Downstream Systems To update the downstream ERP and shipping systems, the validated order will need to be sent via a BizTalk send port via the appropriate adapter. This is demonstrated in Figure 2-4. The adapter to be used depends on what d ownstream system is going to be updated. In the case of the ERP system, if this were an SAP application, the port would use the SAP adapter. The same would hold true if it were an MQSeries queue—the port would use an MQSeries adapter. For the custom shipping solution, a custom adapter will need to be created if no off-the-shelf adapter is available. Note that in this system, the send pipelines are responsible for packaging the message into its appropriate format, adding any security information such as digital certificates, and encoding it properly so that the downstream system can read the order information. The send ports also return a response message back that indicates whether or not the update was successful. What to do with that response message is the responsibility of the caller, not the pipeline, adapter, or send port. These common subsystems also need to be built: • Coordinate fulfillment process. • Get customer information. • Handle errors. • Handle order rejections. CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT 27 Figure 2-4. U pdate D ownstream Systems design 6994ch02final.qxd 10/2/06 12:26 AM Page 27 Creating Your Development Environment Once you have a team established, the next step is to create an environment where you can create, test, and deploy code. Some variables will affect how this is going to be accomplished: • How are the development servers going to be configured? • How will source control be configured? • How are the Visual Studio projects going to be laid out? The answer to each of these questions can often separate a well-organized and efficient environment from one that can kill a team’s productivity. Potential solutions to each of these questions are given in the next sections. Isolated Development Configuration BizTalk development is an isolated development model. This model requires each developer to have a stand-alone development environment and not a shared environment such as in web development. In the isolated model, a developer performs each task independently from other develop- ers on the team. They can code, debug, edit, and restart services without worrying about affecting others on the team. Each developer has a self-contained development workstation with a local BizTalk Server Group. Access to the master source files is controlled via a Visual SourceSafe (VSS) database located on a network file share. Figure 2-5 illustrates an isolated development model. The isolated model of BizTalk Server development provides the following benefits: • No chance that BizTalk Server shared configuration information will interfere with another developer’s work (for example, XML target namespace clashes occurring from multiple installed versions of shared schema) • No opportunity for any one individual’s BizTalk Server deployment and test processes interrupting other users (for example, the starting and stopping of BizTalk Server host instances, receive locations, or dependent services like IIS, SQL, and SSO) • Ability to clear resources like event logs and tracking databases without disrupting other users • Ability for developers to use different versions of shared resources, for example, helper classes and error-handling processes • Ability for developers to attach and debug the BTNTSvc.exe process without halting other developers’ processes CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT28 6994ch02final.qxd 10/2/06 12:26 AM Page 28 Using Virtual Machines M any or ganizations use virtual desktops for development. I n these cases, organizations should look at products such as Virtual PC or VMware to allow developers to have multiple virtual machines running within the same physical hardware. Virtual desktops provide two things w ell. The most important thing is that they allow your developer to get a fresh install in a matter of minutes rather than hours. How many times have developers needed to rebuild their PCs due to bad code they had written, too much unsupported stuff getting installed, or CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT 29 Figure 2-5. Isolated BizTalk Server development 6994ch02final.qxd 10/2/06 12:26 AM Page 29 a bad configuration they might have done? Typically this will happen at least two to three times over the run of a year. Having a fresh virtual image that they can load onto a clean host operating system greatly reduces the time for this to occur. All developers need to do is copy over any files they want to save from the virtual machine onto the host operating system before it is removed. The second thing that virtual desktops allow for is the ability to host multiple configura- tions inside one physical box. Often developers need to have separate versions of either the operating system or a development environment. This is often the case when a developer is coding both BizTalk and classic .NET objects. When the BizTalk development tools are installed and the environment is configured, there are significant changes made to the underlying oper- ating system. Developers will often have a “BizTalk” image and a “.NET” image just to keep things separated. The configuration just described is also often required when creating a web application that targets different browser platforms and versions. Anyone who needs to support IE 5.0, 5.5, and 6.0+ will need to have something similar to this configuration, since these browsers can- not live on the same host OS. Organizing Visual SourceSafe Source Control Not implementing a structured source control process is a sure-fire way to derail a project before it gets started. It is important to model the source control directory structure to one that closely simulates the namespaces and assemblies that are actually stored in the project. For example, assuming that your company name is ABC Inc., the easiest place to start would be to create a root directory called ABC in SourceSafe. Each project that is being implemented at ABC would then get its own folder, for example, FulFillment. The structure would look something like that in Figure 2-6. CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT30 Figure 2-6. Simple VSS project layout 6994ch02final.qxd 10/2/06 12:26 AM Page 30 Notice that the subfolder names are matching up to the proper namespaces for the proj- ects within that SourceSafe project. Once the high-level folder structure is implemented, it easily allows new projects to be added, and organizational namespaces should be self- enforcing. Consider the example of the FulFillment application; in this scenario you can use subprojects that map to the subsystems you need to create. Each subsystem would then have its own namespace, and the SourceSafe project will be named accordingly. Figure 2-7 illus- trates the FulFillment application, its subsystems, and even some sub-subsystems. Before beginning with VSS, ensure that the binary file types for *.btm, *.btp, *.xsd, and *.odx hav e been added to VSS. This is required so that SourceSafe does not attempt to version these file types as text. Structuring and Integrating with Visual Studio There is no standard way to structure a Visual Studio solution that has BizTalk projects included. Essentially, a properly defined naming convention will be applicable whether the solution is a complete .NET solution or a mix of .NET classes and B izTalk artifacts. The key decision to make is whether the entire application will be created as a single VS .NET solution or whether it will be broken down into multiple solutions. Another approach is to decide whether or not to have the Visual Studio solution file controlled under source control at all. In this scenario, each developer has a local solution file that is not under source control. The individual developer then adds the Visual Studio projects to his local solution that are required to complete the application being created. CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT 31 Figure 2-7. VSS solution layout 6994ch02final.qxd 10/2/06 12:26 AM Page 31 How the Visual Studio solutions are structured will have many ramifications on how developers will use the solution, how it will be built, and how it can be packaged and deployed. Additional things to consider are whether each developer will have the BizTalk development tools installed on their workstation. If a group of developers never code BizTalk artifacts and only create standard .NET classes, then these developers will get errors each time they load a BizTalk development project. A configuration like this will not work for a single- solution scenario where every project is included in the solution and is loaded upon startup. In single-solution scenarios, it is necessary to break the solution up into multiple solutions that can be worked on either by BizTalk developers or by .NET-only developers. In cases where multiple developers are working on isolated pieces of a solution, a sepa- rate integration environment should be created. The purpose of this environment is to allow a common area for each build of the application to be placed. Additionally, the deployment process is developed and tested using this environment in order to minimize deployment errors when the solution is moved from the development environment into testing and finally production. Since the BizTalk development model is isolated as described in the preceding section, it is crucial that the integration environment provide a place where unit testing can occur in a controlled environment. The integration environment configuration should closely match what will be used in the QA environment. The actual hardware that is used is not as important as the software. In many situations, given that most projects have limited resources, the inte- gration environment is often a small, single-CPU server or spare developer workstation. Following are some things that should be considered when designing this environment: • BizTalk Server port configuration: Often on a developer’s local workstation, required BizTalk ports will be simple transports such as the file adapter to facilitate easy testing. Also, port filter criteria may be simplified as the entire list of document filters and trans- formations may not be required. The integration environment should try to give the developer as controlled and realistic a configuration as possible. • Strong name key storage: When building BizTalk components that will be deployed to the management database, it is necessary to implement a strategy for how to manage the strong name keys. Since BizTalk assemblies that are deployed need to be stored in the Global Assembly Cache (GAC), and all assemblies in the GAC need a strong name, this means that all BizTalk assemblies will need to use a strong name key. How this is managed often depends on the type of solution. If the solution will be a “for sale” com- mer cial product, it is cr itically important to ensure that access to the strong name key is limited to key team members to ensure that the integrity of the application is main- tained. In this case, developers are often given a test key file that is used to facilitate their building, deplo ying, and testing activities. O nce the code is promoted, the build master then replaces the test key with a production key file. • Restricting code deployed: Only build and deploy code to the integration environment if it is included in the formal build that will be sent to QA. This also helps to keep the integration environment a “managed” environment and not an isolated sandbox like the developer’s local workstation. CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT32 6994ch02final.qxd 10/2/06 12:26 AM Page 32 • BizTalk 2006 MSI exports: Starting in BizTalk 2006, applications can be exported using Windows Installer technology to a Microsoft Installer (MSI) package. This MSI can be customized to include all required BizTalk Server artifacts and referenced assemblies and configuration. The integration environment is the ideal environment for exporting the MSI package to be used for installation in the QA and production environments. The following sections discuss each of these approaches in turn. Single Visual Studio Solution For small- to medium-sized applications (less than 12 VS .NET projects), it is quite feasible to contain all the required Visual Studio projects inside one solution. This one solution is then stored within Visual SourceSafe and is used by all developers, as depicted in Figure 2-8. The one solution shared by all developers is often referred to as the Master solution, and the solution is bound to the application root in SourceSafe. If the example application were structured as a single-solution configuration, it would most likely be named “ABC.FulFillment.sln” and would be bound to the ABC.FulFillment folder in Visual Source- Safe. This configuration has a number of advantages and disadvantages. First some of the advantages: • I t is simple and easy to manage. • The entire solution namespace hier archy is easy to see. Each project will contain only one set of namespaces that will compile to an assembly with the namespace of each class in the assembly equal to the assembly’s physical name. • It allows the entire solution to be built and deployed as a whole without complex build scripts. CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT 33 Figure 2-8. Visual Studio solution layout 6994ch02final.qxd 10/2/06 12:26 AM Page 33 • It allows for references between projects to be project references and not hard refer- ences to a built assembly. This will allow code changes in one project to be automati- cally reflected in any referenced project and helps to ease version conflict issues. • Developers will automatically see any checked-in changes from other developer team m embers. The only action required is to get the latest code check-ins from SourceSafe. And now some disadvantages: • It requires the solution file be checked out from SourceSafe if any new projects are added. Each time a project is added to the solution, every developer will be prompted to connect to SourceSafe and get the latest copy of the newly added project. • Frequent updates to the file cause it to be locked in SourceSafe. Care will need to be taken to ensure that the .sln file in SourceSafe is not checked out for extended periods of time. • It isn’t feasible for teams who don’t have BizTalk installed on every development workstation. • It usually requires that all referenced projects be built along with the main project that is being built. This becomes time consuming as the number of projects increases. • Solution loading time increases as the number of projects increase. This becomes an issue as the number of BizTalk projects and artifacts within those projects starts to increase. Multiple Visual Studio Solutions For larger, more complex projects, it may become necessary to split an application into multi- ple Visual Studio solutions. In this scenario, there are multiple VS .NET .sln files checked into SourceSafe. Each solution would be logically related to a feature of the application that you are implementing. Each .sln file is bound to a directory in SourceSafe and contains the projects that are required to build the solution. This means that all projects within the solution are part of the solution, and referenced assemblies are referenced in the VS .NET project files as refer- ences to assemblies , not references to VS .NET project files. One of the issues with this approach of carving an application into multiple Visual Studio solutions is how to include common project assemblies within each of the multiple solutions. C onsider if there w ere three VS .NET solutions for each of the three subsystems defined in the earlier example. How would each of these solutions reference the Common Utilities project or the shared BizTalk Schemas project? It is possible to include these common projects within each of the solutions . T o have each solution add the project that is needed, you choose the Add Project from Source Control option within the VS .NET solution, as demonstrated in Figure 2-9. CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT34 6994ch02final.qxd 10/2/06 12:26 AM Page 34 The issue with adding the common VS .NET projects to each of the solutions becomes a matter of controlling who is allowed to edit and modify the shared source control. If a team of developers is specifically assigned to make additions and modifications to shared library assemblies, it is more advisable to have these assemblies included as references to the built DLL, rather than the VS .NET project file. The team responsible for these assemblies will deploy the correct version to the integration server and publish the correct build number. Each project that references the DLL must be updated to include the new assembly version number, or the reference must not include the version information and a new assembly is simply overwritten. In a multiple solution configuration, a separate build-and-deploy process is necessary. Since the application is divided into separate VS .NET solutions, there are two approaches to building the solution: • Build and deploy each solution separately. • Create a Master VS .NET solution that includes all VS .NET projects from each solution. Build and deploy this Master solution as a single unit. Advantages of the multiple-solutions approach include the following: • O nly pr ojects that ar e r equired to build the solution are loaded when the solution is opened in VS .NET. This can help decrease the amount of time required to load the solution. • Each solution file is based on a logical application subsystem or feature. The .sln file is then maintained and modified b y the gr oup that o wns that feature. CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT 35 Figure 2-9. Adding a Visual Studio project from source control 6994ch02final.qxd 10/2/06 12:26 AM Page 35 • Configuration allows application to be built and deployed as pieces. This allows teams to build and test their feature independent of others. • It allows the application to incorporate new features without having to dramatically change its layout in Visual SourceSafe. • Contention for Visual Studio .sln files within Visual SourceSafe will be decreased. Each feature team can add/remove VS .NET projects to their solution without affecting developers from other teams. The list of advantages is long, but there are also a few disadvantages to the multiple- solutions approach: • It increases build-and-deploy complexity. • It increases the chances of versioning issues arising from referencing common components. • Increased management is needed. A formal build-and-deploy process becomes essential. Developer-Independent Solutions In some cases, it is possible to not have the VS .NET solution files checked into SourceSafe. In these situations, each developer has a local .sln file that he uses to add/remove projects as he needs; the .sln file is not used to organize the application into its appropriate features. This configuration works well for teams where the .NET assemblies they support are common to several different applications, and the VS .NET project file can be compiled on its own or with minimal references. The build process will need to take this into account by either creating custom build scripts or creating a master .sln file that is used deploy the solution to the inte- gration environment. Advantages of developer-independent solutions are as follows: • It is ideal for small teams or projects with very few independencies. • It is simple. • It is flexible and gives developers control over development environment. As always, there are tradeoffs, this time in the form of the following: • It causes increased build-and-deploy complexity. • Ther e is a potential loss of contr ol for dev elopment leads . • I t still r equires a separate build process or Master solution file. Organizing Artifacts in BizTalk 2006 You’re likely to use BizTalk for more than one application. You’ll then quickly run into the problem of organizing your application artifacts such as ports, schemas, and so forth. There are two facets to organizing. First you must understand the concept of a BizTalk application. CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT36 6994ch02final.qxd 10/2/06 12:26 AM Page 36 [...]... top-level logical grouping for BizTalk artifacts becomes the application instead of the artifact type as it was in BizTalk 20 04, as shown in Figure 2- 11 37 6994ch02final.qxd 38 10 /2/ 06 12: 26 AM Page 38 CHAPTER 2 s STARTING A NEW BIZTALK PROJECT Figure 2- 11 BizTalk 20 06 artifact layout Using BizTalk Explorer to Manage Applications One of the most requested features for BizTalk 20 06 was to give developers... specific ports A diagram of this approach is shown in Figure 2- 20 Figure 2- 20 Versioned deployment using ports 51 6994ch02final.qxd 52 10 /2/ 06 12: 26 AM Page 52 CHAPTER 2 s STARTING A NEW BIZTALK PROJECT Following are the steps involved: 1 Update the assembly version defined within the specific BizTalk project 2 Update the assembly version defined within the associated non -BizTalk assemblies 3 Before compilation,... settings are deployed to the BizTalk Management DB 47 6994ch02final.qxd 48 10 /2/ 06 12: 26 AM Page 48 CHAPTER 2 s STARTING A NEW BIZTALK PROJECT Figure 2- 17 Choosing the MSI destination location Figure 2- 18 Importing a BizTalk Server MSI BizTalk Assembly Naming and Versioning A BizTalk assembly is created by compiling a BizTalk project using VS NET .2 Any artifacts in the project will be included in the... change Combining the Two Approaches You can combine the previous two approaches using versioned schema namespaces in conjunction with versioned receive/send ports This approach is shown in Figure 2- 22 Figure 2- 22 Versioned deployment using ports and namespaces 6994ch02final.qxd 10 /2/ 06 12: 26 AM Page 55 CHAPTER 2 s STARTING A NEW BIZTALK PROJECT The steps involved in the combined approach are as follows:... updated in the VS NET project properties as shown in Figure 2- 14 41 6994ch02final.qxd 42 10 /2/ 06 12: 26 AM Page 42 CHAPTER 2 s STARTING A NEW BIZTALK PROJECT Figure 2- 14 BizTalk project assembling version information The dialog boxes are only relevant for BizTalk assemblies For assemblies that are standard NET assemblies such as pipeline component projects or utility classes, you need to change the assembly... Figure 2- 23 55 6994ch02final.qxd 56 10 /2/ 06 12: 26 AM Page 56 CHAPTER 2 s STARTING A NEW BIZTALK PROJECT Figure 2- 23 Versioned deployment using filtering Use the following steps to implement this strategy: 1 Update the assembly version defined within the specific BizTalk project 2 Update the assembly version defined within the associated non -BizTalk assemblies 3 Before compilation, programmatically update... Before compilation, programmatically update namespaces associated with individual schemas to include references to specific versions (e.g., http://Microsoft .BizTalk/ Service/v1.0.0.0) 6994ch02final.qxd 10 /2/ 06 12: 26 AM Page 53 CHAPTER 2 s STARTING A NEW BIZTALK PROJECT Figure 2- 21 Versioned deployment using namespaces Following are the advantages of the versioned deployment approach: • As BizTalk distinguishes... to the improved deployment model within BizTalk 20 06 that allows the exporting of a BizTalk application to a Windows Installer package Figure 2- 10 BizTalk 20 04 artifact organization Applications can contain any number of BizTalk artifacts such as schemas, business rules, orchestrations, and ports To facilitate such organization, the BizTalk Management tools have been redesigned in BizTalk 20 06 The... failures encountered during the export process The MSI 6994ch02final.qxd 10 /2/ 06 12: 26 AM Page 47 CHAPTER 2 s STARTING A NEW BIZTALK PROJECT package that is created contains the binaries, resources, configuration, and binding file information to import the application on another BizTalk installation as shown in Figures 2- 16 and 2- 17 Figure 2- 16 Exporting an MSI using the BizTalk Administration Console In... BizTalk Server 20 04, your artifacts will also be installed in the BizTalk Application 1 root After the upgrade is complete, it is advisable to create a new logical application container and move the artifacts to it to avoid confusion 39 6994ch02final.qxd 40 10 /2/ 06 12: 26 AM Page 40 CHAPTER 2 s STARTING A NEW BIZTALK PROJECT Figure 2- 13 BizTalk 20 06 Administration Console Creating a Build-and-Integration . developer’s local workstation. CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT 32 6994ch02final.qxd 10 /2/ 06 12: 26 AM Page 32 • BizTalk 20 06 MSI exports: Starting in BizTalk 20 06, applications can be exported. BizTalk 20 04, as shown in Figure 2- 11. CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT 37 Figure 2- 10. BizTalk 20 04 artifact organization 6994ch02final.qxd 10 /2/ 06 12: 26 AM Page 37 Using BizTalk Explorer. deployment. CHAPTER 2 ■ STARTING A NEW BIZTALK PROJECT38 Figure 2- 11. BizTalk 20 06 artifact layout 6994ch02final.qxd 10 /2/ 06 12: 26 AM Page 38 BizTalk s Administration Console BizTalk s Administration