Agile Business Suite Development

Agile Business Suite Development A Guide for Organizing and Configuring for Larger Organizations Plus Usage Best Practices White Paper

Historically with Agile Business Suite (AB Suite), as well as with the previous Enterprise Application Environment (EAE), Unisys has been reluctant to prescribe a development environment configuration for all users. Because the user community is very diverse and the product offers a broad range of features and capabilities, there is no one way to use it. The first part of this paper provides some guidelines for configuring and using the AB Suite development environment for larger organizations. These guidelines are not hard and fast rules. They are recommendations, based on our experience with AB Suite development in a number of larger development sites. The second part of this white paper contains a series of best practices that provide advice on using AB Suite Developer for a team of any size. 2

Table of Contents Introduction 5 High Level Architectures 5 Sample 1 Single-User Development 5 Sample 2 Single-User Development with Version Control 7 Sample 3 Multi-User Architecture with Version Control 8 Sample 4 Multi-User Architecture with Terminal Services 10 Source Management and Migration of Changes 12 Workstation Configurations 13 Minimum Workstation Requirements 13 Recommended Workstation Requirements 13 Server Configurations 14 Version Control Server Configurations 14 Shared Multi-User Repository Server 15 AB Suite Builder Server 15 AB Suite Developer Server Using Terminal Services 15 Development Best Practices 17 Migrating from EAE to AB Suite 17 Model Analysis and Clean-up Before Migration 22 Effective User of a Version Control Tool with AB Suite 23 Testing and Debugging 24 Developer Installation and IC Upgrades 27 Host Generate Tuning and Performance ClearPath MCP Application Builder 28 Tuning and Maintenance of SQL Server 29 Impact of Anti-Virus Software on Developer 30 Additional References 31 AB Suite Support Site Web Page 31 Courses and Workshops 31 Unisys Technical Services 32 Summary and Conclusions 33 3

4

Introduction Historically with Agile Business Suite (AB Suite), as well as with the previous Enterprise Application Environment (EAE), Unisys has been reluctant to prescribe a development environment configuration for all users. Because the user community is very diverse and the product offers a broad range of features and capabilities, multiple ways exist to use it. We have published minimum configurations for workstations and servers; however, because these are minimum requirements, they are not completely satisfactory for larger organizations or for developers working on very large application models. The first part of this paper provides some guidelines for configuring and using the AB Suite development environment for larger organizations. These guidelines are not hard and fast rules. They are recommendations, based on our experience with AB Suite development in a number of larger development sites. These recommendations might not be appropriate for smaller organizations. Also, as they say your mileage might vary, but the guidelines provide a structured approach to configuring an AB Suite development environment that addresses the way your team works. The second part of this white paper contains a series of best practices that provide advice on using AB Suite Developer for a team of any size. High Level Architectures Although many different development architectures can possibly exist that is, the type and number of teams, their functions, and the number of workstations or servers they use four high level architectural schematics summarize the configurations that work well. Sample 1 Single-User Development The most basic AB Suite development configuration is the single-user repository with just one AB Suite Developer and one AB Suite application host. Although this architecture is sufficient for very small development organizations, it quickly becomes unmanageable for larger groups. Relatively few customers have only one AB Suite programmer. Building on this basic configuration, many users have adopted a configuration that is effectively many single-user AB Developer repositories. This architecture is the simplest example for team development, and one that generally works well for very small organizations or for organizations with very small, segregated development teams. The individual users each maintain a copy of the full application in a repository on their workstation; each builds and deploys directly to the server for Test or Production use. The principal attraction to this type of organization is that it allows each developer to be largely independent of the others. This characteristic is especially desirable if the users work in physically separate locations or work on radically different schedules. Also, this configuration can function if they work on different applications or on different parts of a large application. The drawback is that any coordination between the developers and the management of application releases must be performed outside of the AB Suite environment. Developers must periodically export model updates to share with one another and must independently manage who is allowed to deploy what parts of the application, and when. 5

This lack of internal control and oversight is seen as a major disadvantage in organizations with concerns for security and application governance. For example, enforcing the separation of duties required by governance legislation such as Sarbanes-Oxley (in the USA) can be difficult. This type of configuration without the benefit of version control or coordinated, multi-user development is generally not recommended for development organizations with more than two or three AB Suite developers. The following advantages apply to this configuration: Each developer has flexibility and autonomy. Developers have a complete model of the application at their disposal and can build, test and deploy at any time. These disadvantages apply to this configuration: The developers lack coordination for changes between the developers and have no control over what is deployed, when. If each developer is working on a different application or in completely different parts of the same model, this process can work. But for larger applications or for teams of more than two or three, the manual organization required to keep changes straight can cause this type of structure to become unwieldy very quickly even if teams are co-located or communicate on a very regular basis. Recent regulations regarding IT governance require a separation of duties that is not enforced in this model. Meeting these regulations requires a larger degree of external, manual oversight. Figure 1 illustrates the single-user development configuration. SQL Server AB Suite Developer Build & Deploy Dev/Test/Production SQL Server AB Suite Developer Client Deploy End User Web Server Figure 1: Single-User Development Configuration 6

Sample 2 Single-User Development with Version Control The second example is the next logical step for organizations that want to preserve the autonomy of the development environment but also want to add a level of control over what is deployed and by whom. Control is added by introducing source change management, or version control. In this case, each user still maintains a unique copy of the entire application model in their local repository; however, the user is not allowed to build and deploy directly to the host. In most cases, a single user usually a team leader or administrative user is given permission to build and deploy the application. Other users are either not given the administrative rights to deploy or are prevented by local policy. When a build is done, the current changes are extracted from the version control repository. Nothing is allowed to be deployed if it has not first been checked in to the version control repository. In some cases, especially in larger organizations, a separate machine is specifically designated as the build machine. All system builds are performed from this single, dedicated machine. Changes are propagated from Test to Production. In some cases, the administrator builds and deploys the changes from a production version in the version control repository. In other cases, the administrator performs a runtime transfer from Test to Production. The following advantages apply to this configuration: Each user maintains a copy of the full application model in their Developer repository. No concern about interference by other developers exists. Release management and governance are provided by version control and by having a single point for all system builds. With version control, you can maintain an audit history of all changes that go into a given release of the application, and if required, you can recreate a previous version of the application. Figure 2 illustrates single-user development with version control. Build & Deploy SQL Server AB Suite Developer Version Control Build & Deploy Dev/Test Runtime Transfer Production SQL Server AB Suite Developer Client Deploy End User Web Server Figure 2: Single-User Development with Version Control Configuration 7

These disadvantages apply to the configuration in Figure 2: Developer users do not have access to any in-process changes by other developers until they have been formally checked in to the version control system. Larger workstation configurations might be required. An additional workstation or server, and additional disk storage might be required to host the version control repository. This configuration style can work for some larger organizations because it introduces governance through the use of a version control repository and prevents unwanted or unauthorized changes from being introduced into the production environment. The version control repository can take the place of a multiuser model repository if the level of interaction between the individuals is relatively small or infrequent. Sample 3 Multi-User Architecture with Version Control With EAE, a firm delineation existed between a single-user and a multi-user repository. If the EAE Developer was opened in single-user mode, no other developers would be allowed to open that repository. Because AB Suite is implemented as a package within Visual Studio, it is essentially a multi-user environment by default all of the time. The distinction comes from which SQL Server repository you are using, and whether or not it is local or being shared by other developers. The examples in Sample 1 and Sample 2 assumed that each user connects to their own unique SQL Server database making them single user because no other users have access to their model repository. To provide multi-user access, you simply connect the AB Suite Developer to a shared SQL Server database. This third example uses a centrally located SQL Server database, along with a shared version control repository, to provide a true multi-user development environment. It is depicted in Figure 3. Version Control Build & Deploy AB Suite Developer Build & Deploy Dev/Test Runtime Transfer Production AB Suite Multi-User Repository Client Deploy AB Suite Developer Web Server End User Figure 3: Multi-User Architecture with Version Control 8

When a build is performed, the current changes are extracted from the version control repository. Nothing is allowed to be deployed if it has not first been checked in to the version control repository. As with Sample 2, larger organizations often dedicate a separate machine as the build server. Changes are propagated from Test to Production. In some cases, the administrator builds and deploys the changes from a production version in the version control repository. In other cases, the administrator performs a runtime transfer from Test to Production. The following advantages apply to the architecture shown in Figure 3: With a multi-user repository, each user has immediate visibility to changes made by other users. In-process changes are locked to prevent modifications by other users. The storage requirements for each developer s workstation are smaller because the multi-user repository is kept on a central SQL Server database server. Release management and governance are provided by the use of version control and having a single point for all system builds. With version control, you can maintain an audit history of all changes that go into a given release of the application, and if required, you can recreate a previous version of the application. These disadvantages apply to the architecture shown in Figure 3: Developers working in the same area of the model can interfere with one another builds requested by one user might fail or be delayed if resources are locked by another user s in-process changes. Larger workstation configurations might be required This configuration is relatively common for medium and large organizations. Coordination is required to keep users segregated, but this requirement is often offset by the immediacy of the multi-user repository. A similar configuration can be defined that eliminates the version control repository and simply relies on manual processes to extract and back up changes at significant events. However, this configuration can become very cumbersome and error-prone, especially for larger teams or larger applications. Unisys strongly recommends using a version control tool for managing releases and for migrating changes from various levels of testing into production. 9

Sample 4 Multi-User Architecture with Terminal Services Rather than provide powerful workstations for all development personnel, some very large organizations opt to host the AB Suite Developer on a large Windows server and allow the users to connect through Terminal Services or similar technology (for example, Citrix). With this configuration, the users workstations can be smaller machines without impacting the productivity of the user. This configuration also opens up more possibilities for remote workers and for support and administration activities outside of regular office hours. As with previous configurations, Unisys strongly recommends version control to manage releases and migration of changes from test to production. The version control repository can reside on the same server with AB Suite or on a separate server, whichever is most appropriate. You can use a separate build server, or you can maintain a server partition and a separate SQL Server database instance that are dedicated for system build functions. Figure 4 illustrates this architecture. Another benefit of this type of configuration is that it is much easier to provide the same Developer configuration for all users and to distribute updates without the need to install custom software on all workstations. Version Control Build & Deploy AB Suite Multi-User Repository Build & Deploy Dev/Test Runtime Transfer Production Client Deploy End User AB Suite Developer (Thin Client) AB Suite Developer (Thin Client) AB Suite Developer (Thin Client) Web Server Figure 4: Multi-User Architecture with Terminal Services 10

These advantages apply to the architecture shown in Figure 4: With a multi-user repository, each user has immediate visibility to changes made by other users. In-process changes are locked to prevent modifications by other users. A wider variety of workstation configurations can be used effectively. You do not need to upgrade every user s desktop at the same time. Remote and out-of-hours accesses (if network access policies permit) are easily accommodated. AB Suite Developer maintenance is simplified because operations can update the desktop image on the server. This process reduces or eliminates the need to install interim corrections (ICs) and other software updates on individual workstations. Release management and governance is provided by version control and by having a single point for all system builds. With version control, you can maintain an audit history of all changes that go into a given release of the application, and if required, you can recreate a previous version of the application. This configuration allows the Developer server and the Repository to be on the same server, or at least adjacent, on the same LAN segment. This avoids many performance issues that arise from having a remote database server. These disadvantages apply to the architecture shown in Figure 4: A larger, central Windows server is required to support several concurrent Developer sessions. If the users are sharing the Developer repository, developers working in the same area of the model can interfere with one another builds requested by one user might fail or be delayed if resources are locked by another user s in-process changes. Extra configuration is required for Debugger. Each concurrent Debugger user requires their own configuration, which means it is easy to get the configurations out of sync. Without this additional capability, only one user can debug a given system or report at a time. If COM, COM registration of the.net or GAC (Global Assembly Cache), or other services are used, development with Visual Studio other than for AB Suite might be restricted. This configuration is becoming common for medium and large organizations. In some geographies, it is being recommended for smaller organizations. It is quickly becoming the preferred configuration for any AB Suite development with more than just a few users. 11

Source Management and Migration of Changes Whether the development architecture consists of a single large server, as in Sample 4, several well-configured workstations using a multi-user repository, single-user repositories, or a combination of these, Unisys strongly recommends using a version control product and a separate repository to manage system builds. Figure 5 shows a typical example of migrating model changes from Development into Test and Production use. The numbered items after the figure correspond to those numbers in the figure and explain the flow. 2 Version Control Repository 4 AB Suite Administrator 5 1 AB Suite Multi-User Repository (DEV) AB Suite Single-User Repository (TEST) 3 AB Suite Single-User Repository (PROD) Build & Deploy Client Deploy Web Server Build & Deploy Dev/Test Runtime Transfer 6 Production AB Suite Developer (Thin Client) AB Suite Developer (Thin Client) AB Suite Developer (Thin Client) End User Figure 5: Multi-User Environment with Version Control and Multiple Repositories 1. All rank and file developers perform their work in the primary Developer repository (DEV). Under normal circumstances, they cannot access the TEST or PROD repositories. 2. When a developer (or development team) is ready to test their changes on the AB Suite host, they check the changes into the version control system. A label is assigned to identify the nature or reason for the change. 3. An administrative user then extracts all changes that are ready for testing into the TEST AB Suite Repository and performs a build targeting the TEST runtime environment. 4. Steps 1 through 3 might be repeated until all testing is complete and any errors are corrected. Once testing completes, the administrator updates the changes in the version control repository with a label to indicate the status or release level. 5. To release the changes into production, the administrator can either extract the changes in this release (by label) into a separate (PROD) AB Suite Repository from which the new version of the application is built and deployed OR 6. The administrator performs a runtime transfer of the fully tested version from the TEST runtime environment to the PROD runtime environment. 12

In many cases the administrative user identified in the steps listed above is a team leader or other member of the development team who has been designated to act in this administrative capacity. In some organizations, because of regulatory requirements or other business reasons, the migration and installation of changes or releases from Test to Production is carried out by a different group of people. In many cases, development personnel are not allowed to have privileged access to the applications in the Production environment; this restriction avoids the possibility of changes being introduced into the Production system without proper oversight. Some organizations do not allow the existence of a compiler on the Production system to further restrict the possibility of unauthorized changes. In that case, all changes must be migrated using Runtime Transfer, after being thoroughly validated in a Test environment. At the appropriate points in steps 3, 5 and 6, updated client interfaces (for example, ASP.NET Web Forms) are deployed to the web servers or other client environments. Workstation Configurations The workstation configurations provided in the AB Suite documentation tend to be the minimum workstation requirements for running AB Suite, providing adequate performance with a small application model. Based on the experience of AB Suite users with larger applications, and larger teams, we provide the following recommended configurations. Minimum Workstation Requirements According to the Agile Business Suite Installation and Configuration Guide for Release 2.0, the minimum workstation requirements are as listed in Table 1. These are not the recommended workstation or server requirements for most organizations. Hardware Developer Developer and Builder Processor Intel Pentium IV Intel Pentium IV 2.0 GHz 2.0 GHz RAM 2 GB 2 GB Disk Space 2 GB* 2 GB* Other SVGA Monitor SVGA Monitor CD-ROM Drive CD-ROM Drive Paging File - 300MB * For one medium-to-large size AB Suite application model, you should allow at least 1 GB in SQL Server for each copy of the model. Table 1: Minimum Workstation Requirements Recommended Workstation Requirements The minimum workstation requirements listed in Table 1 might be adequate for users working with a relatively small application. However, most users would find the experience relatively frustrating, especially if they are working with one or more very large AB Suite models or if they are running a variety of other applications along with AB Suite Developer. AB Suite Developer 2.0 is supported on the following operating systems: Windows XP Professional SP3 Windows Server 2003 SP2 Windows Server 2003 (x64) (WOW64) SP2 Windows Vista Business Edition SP1 Windows Server 2008 SP1 Windows 7 13

Currently, we have had the most experience, and best results, with Windows XP Professional and Windows Server 2003. The specifications listed in Table 2 are more realistic for typical AB Suite Developer users. Hardware Developer Developer and Builder Processor Intel Pentium Dual Intel Pentium Dual Core 2.5 GHz or Core 2.5 GHz better (Note: a few or better (Note: a faster processors few faster are better than processors are many slower better than many processors or slower processors cores) or cores) RAM 3 GB for XP 3 GB for XP 4 GB for others 4 GB for others Server Configurations The four types of server configurations considered for AB Suite Developer are Version Control Server Shared Multi-User Repository Server AB Suite Build Server AB Suite Developer Server running Terminal Services Version Control Server Configurations A version control product can reside on the workstation or server where AB Suite Developer resides or on a server on its own. Refer to the configuration guidelines for your version control tool of choice. In general, the most significant requirement is enough disk space to handle many versions of AB Suite model changes. The requirement for disk space is likely to increase over time as the application moves from initial development, through testing, and potentially many production releases. Disk Space 2 GB* 2 GB* Other Large, Wide-screen Large, Wide-screen Monitor Monitor CD-ROM Drive CD-ROM Drive Paging File Paging File Equal to System Equal to System RAM RAM * For one medium-to-large size AB Suite application model, you should allow at least 1 GB in SQL Server for each copy of the model. Table 2: Recommended Workstation Requirements 14

Shared Multi-User Repository Server A shared multi-user repository server primarily functions as a database server. The best recommendation for this type of server is a small number of very fast processors with large amounts of memory and disk. Table 3 lists the recommended requirements for this server. Hardware Processor RAM Disk Space Other Developer and Builder Intel Pentium Dual Core 2.5 GHz or better (Note: a few faster processors are better than many slower processors or cores) 4 GB/processor 2 GB* CD-ROM Drive Paging File Equal to System RAM * For one medium-to-large size AB Suite application model, you should allow at least 1 GB in SQL Server for each copy of the model. Table 3: Recommended Requirements for Shared Multi-User Repository Server AB Suite Builder Server The best recommendation for this type of server is a small number of very fast processors with large amounts of memory and disk. Table 4 lists the recommended requirements for this server. Hardware Processor RAM Disk Space Other Developer and Builder Intel Pentium Dual Core 2.5 GHz or better (Note: a few faster processors are better than many slower processors or cores) 4 GB/processor 2 GB* CD-ROM Drive Paging File Equal to System RAM * For one medium-to-large size AB Suite application model, you should allow at least 1 GB in SQL Server for each copy of the model. Table 4: Recommended Requirements for AB Suite Builder Server AB Suite Developer Server Using Terminal Services Although AB Suite is supported on several variants of the Windows operating systems, for this purpose we recommend a true server operating system for this type of server either Windows Server 2003 Enterprise Edition (SP2) or Windows Server 2008 Enterprise Edition (SP1). Although using virtual servers (VSs) enables multiple versions of AB Suite releases or ICs on a single server, virtualization can impact performance. Therefore, you should increase the speed and number of physical processors as appropriate. 15

Table 5 lists the recommended requirements for this server. Hardware Processor RAM Disk Space Other Developer and Builder Intel Pentium Dual- or Quad-Core 2.5 GHz or better Multiprocessor configurations 4 GB/core 2 GB* CD-ROM Drive Paging File Equal to System RAM * For one medium-to-large size AB Suite application model, you should allow at least 1 GB in SQL Server for each copy of the model. Table 5: Recommended Requirements for AB Suite Developer Server Using Terminal Services Customer Example Consider an example where a customer recently migrated a large application from EAE to AB Suite. Unisys recommended the following configuration: On this server the customer is running AB Suite Development for four concurrent users, as well as running Debugger, and performing Builds for MCP. This is all done using Microsoft Terminal Services. They are also using this environment for other Visual Studio development, and hosting the Visual Basic.NET clients for their end users. We estimate this configuration could comfortably handle 10 concurrent developers. More Information about Using Terminal Services Refer to the Agile Business Suite Installation and Configuration Guide for Release 2.0 for a description of the procedure for installing AB Suite Developer with Windows Terminal Services. a dual, quad-core system (2 sockets with 4 cores each, for the equivalent of 8 processors) 6 GB of memory 16

Development Best Practices Some best practices for development are grouped in these topics: Migrating from EAE to AB Suite Model Analysis and Clean-up Before Migration Effective Use of a Version Control Tool with AB Suite Testing and Debugging Developer Installation and IC Upgrades Host Generate Tuning and Performance ClearPath MCP Application Builder Tuning and Maintenance of SQL Server Impact of Anti-Virus Software on Developer Migrating from EAE to AB Suite The majority of AB Suite users to date had their first exposure to AB Suite as a part of migrating an application from EAE. This paper does not provide detail about the migration process. However, the few points noted here can help make your first AB Suite experience a positive one. What Safe Passage Means for Migration The concept of Safe Passage as defined here, was introduced to AB Suite because, frankly, many users had difficulty in migrating between previous versions of EAE. In a nutshell, the safe passage commitment is that you should be able to extract a full, validated model from EAE release 3.3 and then import that model into AB Suite. Unisys wants to make the process as error free and simple as possible, while at the same time recognizing that AB Suite is not just the next release of EAE. For that migration, you should not need to make any changes to the application model; you should only need to adjust the Configuration Properties. And you should be able to build and deploy that application to the same type of runtime platform, without errors, and get the same runtime results. Safe Passage is not an open-ended guarantee that everything in AB Suite will be just like EAE. But we do try to ensure that where differences exist in the development environment or in the way application components are created and deployed in the new environment that they are logical, and compatible with the behavior users have come to expect with EAE. Safe Passage does not apply to cases in which you are changing the deployment platform. Nor does it necessarily apply to the way an application model might be modified and maintained. Object Names versus GUIDs Many differences exist between EAE and AB Suite. The AB Suite model is much more object-oriented, and the internal structure of an AB Suite model is very different from that of an EAE model. One of the key differences you might notice as you begin to use AB Suite is the way objects are identified within the model. In EAE, all objects were identified and organized by their names. That convention implied a restriction that the name of each object had to be unique throughout the model. For example, only one definition of an object called Customer or Address could exist. With AB Suite, this restriction is removed, and the model is much more flexible because of applying a GUID (Global Unique Identifier pronounced like Goo-ID ) to each object. GUIDs are maintained internally within the model and not visible to the users. The use of GUIDs allows developers much greater freedom in naming objects. When names are not required to be unique within the model repository, it is easier to merge functionality from other models or designs. One complication emerges, however, when we begin migrating applications from EAE into AB Suite. The first time you import your EAE model the objects are automatically converted to AB Suite objects with a GUID assigned. If you only ever imported an EAE model once, no problem would occur. But in reality, people continue to make changes in the EAE version of their application, and then re-import the model. Importing into the same AB Suite model repository causes new GUIDs to be created, which can result in duplicate objects. If you are certain that you will only migrate an EAE model in its entirety one time into AB Suite and that you will never go back to make changes in EAE, you don t need to worry about any of this. But if you might make a change in EAE at some point during your migration that you will need to bring forward into AB Suite, you need to be aware of the migration database. 17

Using the AB Suite Model Import Migration Database The AB Suite migration database was invented to be the translator between an EAE (name-based) and AB Suite (GUID-based) model. When EAE objects are imported into a migration database, each object is assigned a new GUID, just as when they are imported into a standard AB Suite model. However the migration database remembers where the object came from and maintains a mapping between the EAE object names and the AB Suite object GUIDs. This mapping enables you to make model changes in both EAE and in AB Suite and then to re-import EAE changes into the AB Suite model without duplicating the objects that were already imported. The result of using the migration database is that application maintenance does not need to be frozen during the entire migration process. You can continue to make changes in your EAE application and migrate those changes into AB Suite at any time. The AB Suite Model Import Wizard allows you to import full or partial models from either EAE or AB Suite model extract files. (EAE models are exported with a file extension of.mdl; AB Suite models are assigned the extension of.model.) When you import a new EAE model (for example, SAMPLE.MDL) and the destination model is a new database, you are given the option to specify this as a migration database. Figure 6 illustrates the opening screen of the wizard with the migration database option set. For a given EAE/AB Suite application, you would typically create one migration database. This migration database is used solely to import model information from EAE. To create a working AB Suite model, you would then Export from the migration database (SAMPLEMigration in this case) and Import into a new AB Suite model. You should keep the migration database in tact for any subsequent changes to the EAE version of the model. How does it work? Figure 6: Model Import Wizard with Migration Database Option Set 18

If you make changes in EAE, you can export those changes and import them into the same migration database. The Model Import Wizard recognizes the existing objects in the migration database and does not assign new GUIDs. Then you can export the new changes from the migration database, import them into your working AB Suite model repository and continue working. Figure 7 illustrates this export and import flow. You can use a single migration database to support several versions of your EAE and AB Suite applications. For example, if you have Production, System Test and Development versions of your models in EAE, you can maintain and migrate them all through a single AB Suite migration database. Even if you do not expect to make changes in EAE that would later need to be migrated to AB Suite, we strongly recommend using the migration database with each application you migrate from EAE to AB Suite. For more information on the migration database, please refer to the white paper Migrating from an EAE Environment to AB Suite on the AB Suite Support Web site. EAE Agile Business Suite 2.Export & Import Production Repository Production Model Database 1.Migration MDL File Migration Database Figure 7: Using the Migration Database 19

Advanced Migration Options (Possibly Improve Performance): Intersystem AUTOs EAE uses the AUTO; command for two very different purposes. In one case, it stores data into a local database. In another, it sends a transaction message to an Ispec in another EAE application. In many cases, the variant used is determined at runtime by the value of a global variable. In order to improve design clarity and runtime performance, AB Suite implements this functionality as two different methods on an Ispec class. These methods are the Store() and Send() built-in methods. For new application functionality that is developed within AB Suite, the decision to use the Store() or Send() method is obvious. The appropriate selection avoids ambiguity. However, in an application that is migrated from EAE to AB Suite, the intent of the AUTO; statement is not always obvious. To provide the equivalent runtime behavior, a special method is provided StoreOrSend(). This method only appears in an application that has been migrated from EAE, and if it is present AB Suite must generate a significant amount of extra code. Because the intent cannot be derived from the logic, it is necessary to introduce three methods for each variation of the AUTO; statement in EAE: A Store() method must be provided for the local database update. A Send() method must be provided for the remote Ispec invocations. The special StoreOrSend() method must determine at runtime which of the other methods should be called. For most applications, this choice is not a serious concern because the additional code that is generated is relatively small. However, if your application contains hundreds of Ispec objects and many of them are the target of AUTO; statements, the number of additional methods that are required could be significant. This additional code can have a strong impact on the time required to build your application. Figure 8 illustrates the wizard LDL + Migration Settings. 20

Figure 8: LDL + Migration Settings 21

In order to give you more control over the built-in methods that are created for your application, the AB Suite Import Model Wizard provides an option (under Advanced Settings LDL+ Migration Settings) that allows you to specify which methods should be created. The options include: Default Create the StoreOrSend() methods as described above. As Ispec.Send() Always assume the AUTO; is a remote Ispec invocation. As Ispec.Store() Always assume the AUTO; is a local database update. File specifying Ispecs to be migrated as Store() or Send() Allows you to specify on an Ispec-by-Ispec basis. If you understand the behavior of your EAE application when AUTO; statements are used, making appropriate selections in this Import option menu can improve both the generate performance and the legibility of your AB Suite model. Click the Help button to refer to online documentation in the AB Suite Model Import Wizard for more information on this option. Model Analysis and Clean-up Before Migration In general, you should be able to export any valid model from EAE 3.3, load it into AB Suite, build and deploy it to the same runtime platform. You should have the same functionality as before. However, by completing a few relatively simple tasks before you export the model from EAE, you can make the process easier, and you might improve the usability of your AB Suite model. In some cases, you could even improve performance. Before you extract the EAE Model, you need to prepare by completing these tasks: Organize the EAE Model into functional areas and activities Delete old configurations from EAE Analyze the use of AUTO (WRITE&CLEAR) Organize EAE Model into Functional Areas and Activities EAE allows two levels of logical organization: Functional Areas and Activities. These organizations do not alter the physical structure of your application; they simply make it easier to organize and understand what is there. AB Suite provides a similar concept using the common metaphor of folders. With AB Suite, the number of folders you can have is unlimited as is the depth of nesting of folders. Objects in EAE that have been organized into Functional Areas and Activities are automatically organized in comparable folders in AB Suite. In addition, common items such as GSDs, Dictionaries, and Bundles are also placed in appropriate folders in the AB Suite model. So if you have not already done so, you can create Functional Areas and Activities before you export your EAE model. For example, some people find it helpful to create special Functional Areas for types of objects, like ISPECS, GLGS, REPORTS, and so forth. Others create object groups as Activities within Functional Areas that they might have already defined. At this point, you should also perform some high level analysis of your model and remove any objects that you know you no longer need. For example, many groups write one time Reports that are never removed from the model. If you have a Report named something like ACCTFIXUP092003, a good chance exists that you can delete that Report without any adverse effects. Delete Old Configurations from EAE In EAE each time you generate a model, a previous configuration is created. Most people never clean out older configurations, even months after a version of their application is released into production. In some cases hundreds of older configurations could be included in an EAE model export file. When these old configurations are loaded into AB Suite they are not useful, and they increase the size of the import file. Also, they can greatly increase the amount of time required to validate the model and might show up as spurious errors. 22

For example, if items from previous configurations have been subsequently deleted from the model because they are no longer required, an error might occur. To remove old configurations, open the EAE Model System Directory and perform these steps: Select Previous Configurations from the View menu Delete all of the entries under the Previous Configurations tree node Right-click on System directory and select Synchronize Performing these steps updates the system directory with any changes and deletions since the last time the system was generated and ensures that only the current configuration is migrated to AB Suite. The result is a more efficient model load that does not contain references to configurations or deleted objects that are no longer used. Analyze the Use of AUTO (WRITE&CLEAR) Historically, many programmers have used the WRITE&CLEAR option on the AUTO; command when a simple AUTO: WRITE is sufficient. In AB Suite, using that construct can result in significant extra code being executed when deployed to ClearPath MCP. You might find that it is easier to analyze your usage of WRITE&CLEAR in EAE prior to migrating to AB Suite. If you convert those constructs that are appropriate to simple AUTO; WRITE, the result could be an improvement in your runtime performance. As with development in general, we have seen many different ways to use version control for source change control or release management. The usage varies depending on The way users develop their applications How frequently the applications change The size of the staff Whether they need to only support AB Suite applications or AB Suite plus other workstation-based languages We believe it is very important for AB Suite developers to use version control. At the very least, any model changes that are promoted from any level of test into production should be captured and documented in a version control repository. Because so many options and possibilities exist, we strongly recommend using the AB Suite Version Control Workshop (course CEL8019) to develop the version control/release management process that is right for your organization. Figure 5 in a previous section outlines a typical example of migrating changes from Development, to Test, to Production. Your environment might have a similar number of repositories and migrate changes in a similar fashion, or you might have fewer or more levels of testing. Through the Version Control Workshop, Unisys can help you determine the best combination of repositories and processes to satisfy your unique needs. Effective Use of a Version Control Tool with AB Suite Several years ago, Unisys introduced version control with EAE. Because it was a separately priced product and used non-standard technology that could not also be used with other application development tools, relatively few users chose to use it. Those users that did, by and large, were very pleased with the results. When Unisys developed AB Suite, we addressed this objection to EAE version control by using a standard interface to version control, the Microsoft SCC Application Programming Interface (API) (Source Change Control API). With AB Suite, users can use any version control product that supports the SCC API. 23

Testing and Debugging AB Suite contains some debugging and testing capabilities that did not exist in EAE. This topic highlights some of the differences, and at a high level, describes some preferred ways to use the Debugger to its best advantage. Debugging in EAE consisted of a separately executable program called Developer Test. Developer Test would read the EAE model from the Developer Repository and interpretively execute the user logic. Developer Test used a D-ISAM (Dynamic, Indexed Sequential Access Method) data store. Running on a workstation, EAE Developer Test would execute the LDL logic and perform comparisons and tests using the ASCII collating sequence. This behavior meant that if the ultimate target platform was ClearPath MCP, an EBCDIC machine, some of the tests might give incorrect results if the data that was retrieved from the database was in a different order. To compensate, some users have coded conditions to explicitly handle the differences when the application is running on a workstation (with Developer Test) or on an MCP system. In contrast, AB Suite, which is a package in Visual Studio, uses the Visual Studio Debugger. Like Developer Test, it interpretively executes the LDL+ logic from the Developer repository; thus, you do not need to generate or compile the application before using the Debugger. However, with the AB Suite Debugger, you don t even need to leave Developer. Simply start the Debugger by selecting the appropriate menu option or pressing the appropriate function key. For the first time that you are running the Debugger, you must first use the AB Suite Administration Tool to create a SQL Server database instance for the application. The Debugger initializes the tables as a part of its reorganization phase. If the database already exists, you are given the option to have AB Suite reorganize the database if any changes that affect its structure have been made. C# wrappers for graphical user interfaces, using WinForms, are generated and compiled just-in-time. AB Suite supports an Edit and Continue feature that allows you to change the logic and continue executing the Debugger without restarting the debug session. This feature can be a tremendous time saver and aid to productivity because it enables developers to try out their logic changes without the need to restart the session and navigate to the same point in the logic. The AB Suite Debugger pays attention to the currently selected configuration, and if it is an MCP configuration, executes the logic as if it were running on ClearPath MCP. It stores data into the SQL Server runtime database in EBCDIC, and all of the comparisons are performed using the EBCDIC collating sequence. This action means that the logic behaves the same in Debugger as it behaves when the application is built and deployed on a ClearPath MCP server. In contrast, EAE did not have this ability, and users would either need to be aware of the differences between a Windows and ClearPath MCP runtime environment and compensate for them in their testing or to run more tests on the target MCP platform. AB Suite also supports an HDBA (Host Database Access) mode that allows you to access data directly from a generated target platform. That capability means that when you execute a database command like a Determine, Lookup, or ForEach it retrieves the data records from the Data Management Server (DMS II) database on the target MCP platform, rather than the local SQL Server database. When you start a Debugger session, a C++ system wrapper is generated and compiled, as well as wrappers for each of your reports. This generation operation is completed each time you begin a Debug session. Organizing Reports into smaller groups using folders allows your Debugger session to start faster because it does not create wrappers for Reports you are not going to use. 24

Finally, the other very significant new feature in AB Suite (release 2.0) is the Automated Test Tool (ATT). The ATT enables you to execute transactions against a live generated application using ASP.NET, Visual Basic.NET, or WinForm clients. It captures the inputs and outputs for each transaction as a test case and stores them in XML format on the local workstation or file server. You can edit and save these captured test cases and then easily rerun them later, providing a very effective unit or regression testing capability. So when and how should you use each form of testing or debugging? Table 6 compares these capabilities. Capability Advantages Disadvantages Best Used For Interactive Debugger (Using Windows Configuration) Instant startup from within Developer Edit and Continue SQL Server Database access might result in slower performance with very large databases Execution may be dependent on collating differences between ACSII and EBCDIC for systems targeting an MCP platform Interpretive debugging and unit testing where relatively small databases are required Systems targeting a Windows runtime platform Interactive Debugger (Using MCP Configuration) Instant startup from within Developer Edit and Continue Faithfully emulates MCP environment EBCDIC Tool provided to enable external viewing and editing of database and flat files SQL Server Database access may result in slower performance with very large databases External viewing or editing of database and flat files requires the use of EBCDIC Tool Interpretive debugging and unit testing where relatively small databases are required And where platform-specific execution for MCP is required Interactive Debugger with HDBA (Using MCP Configuration) Instant startup from within Developer Edit and Continue Faithfully emulates MCP environment Retrieves data directly from DMS II database Supports very large databases Eliminates need to transfer large database from one platform to another Enables debugging of datadependent problems using live host-based data Connecting to a remote MCP server to access the DMS II data may result in slower initial performance Interpretive debugging and unit testing with small or large databases And where platform-specific execution for MCP is required Useful for debugging datadependent problems with large amounts of data Table 6: Comparison of Debugging Capabilities 25

Capability Advantages Disadvantages Best Used For Automated Test Tool Easy to use Automates capture, and play back of test cases Works with generated ASP.NET and Visual Basic.NET clients Test case capture can be done by non-development personnel Test case playback can be done by people who are not experienced with the application Requires build/rebuild of the application (i.e. does not work against Debugger) Requires Component Enabler-based clients Does not work with character based clients, Presentation Client and ASP clients Unit testing and regression testing of existing application components Ideal for automated regression testing after a system Build or Rebuild Can be used by less experienced, lower skilled personnel Easy to edit test cases Scripted execution allows automatically incorporating unit or regression tests into build/release process No additional charge; it is included with AB Suite Developer 2.0 Table 6: Comparison of Debugging Capabilities To summarize the testing and debugging information: Do not think of AB Suite Debugger as a one-for-one replacement for EAE Developer Test. Use Debugger for local testing of small units with relatively small databases. Always use the appropriate platform configuration to be sure to get accurate testing for the target platform. Thus, do not always use a Windows configuration for Debugger if you are only deploying to a ClearPath MCP host. Use ATT to perform automatic regression and unit testing. Consider making ATT an integral part of your release process. Require developers to submit updated ATT test cases when functionality changes result in legitimate differences in transaction behavior. One of the basic tenets of the agile development methodology is frequent, small builds. The idea being that compiling and testing small changes is more efficient than saving up a huge number of changes and trying to test and debug everything together. AB Suite development fits this sort of methodology very well. 26

Developers should use the Debugger to test and debug their changes on a unit basis. Once satisfied, they should check them into the version control system and submit them for a build. The build process can include some automatic regression testing using ATT. If testing of the deployed application indicates errors, the developer can use Debugger with HDBA to interactively debug the logic error using data from the MCP host. Even with the advanced debugging capabilities in AB Suite there is no substitution for running the application in its live target environment. Be sure to allow for some further testing of the application after it has been built and deployed to its target runtime platform environment. Developer Installation and IC Upgrades Windows can be a relatively complex environment to manage with many options to take into account. Because AB Suite Developer runs as a package within Microsoft Visual Studio and requires special administrator and application user privileges, you might make a small mistake in the initial installation that might not be noticed until days or weeks later. To help eliminate these problems, we introduced two new capabilities in the AB Suite 2.0 release. The first capability is the ABReady utility. You can use this utility to check the Windows environment for prerequisite software requirements needed by Developer, Client Tools and the Windows Runtime products. You can also use it to install or validate user codes to be sure they have the minimum required permissions. ABReady is included on the AB Suite release media, and you can also download it from the AB Suite support web page. The second capability in the 2.0 release is that the Developer and Windows Runtime installation process checks for many of the same environmental requirements and allows configuring or installing the user codes as is done with the ABReady utility. When installing changes, in the form of Interim Corrections (ICs), we have found, again because of the complexity of the Windows environment, that some product components might not be completely removed before the new version is installed. This situation is especially true if you have skipped several ICs in the process. The best situation is for you to completely remove the previous version of AB Suite before attempting to install the IC. You do NOT need to remove the databases. When you prepare to install a Developer IC, you can remove the current version using the Add/Remove Programs option in the Windows Control Panel. Once the product components have been completely removed, begin the installation process. Start with the GCA release CD and continue to the point that it asks for confirmation of the product license. At that point, after accepting the license, stop the installation at the next opportunity. This action sets up the registry to indicate that you have a valid version of the product and have agreed to the license terms. Next, complete the installation using the IC release media. If required, use the AB Suite Model Migrator tool to update each model database to the version of the IC you have just installed. Note: Beginning with AB Suite IC 2.0.1300 it is no longer necessary to begin the installation of the Developer and Runtime for Windows.NET or Client Tools products with the release (GCA) CD. You can start the installation directly from the IC media. The installation process may ask you to insert the release CD for validation (so don t lose it), Always check the README file with each IC release and follow any special instructions. We recommend completely removing the previous version of the Developer, Client Tools and Windows Runtime products before installing a new IC. We recommend that for any new installation you download and run the latest version of ABReady before you begin to install the AB Suite software. Verify that all of the environmental software is properly installed and that the user codes you plan to use with AB Suite development are properly configured. 27

Host Generate Tuning and Performance ClearPath MCP Application Builder Much of this paper focuses on ways to configure and use the AB Suite Developer, which runs with a Windows operating system. However in building and deploying the application, a significant part of the development activity involves interaction with the target runtime host. This topic explores ways to fine tune the AB Suite Application Builder performance for a ClearPath MCP platform. Configuring AB Suite If you configure AB Suite with the default settings, it performs reasonably well for small-to-medium application models that run on a one or two processor machine. However, a few additional settings can improve overall generate performance if you are using a multiprocessor MCP platform. The Agile Business Suite Runtime for ClearPath MCP Administration Guide (3833 4033) describes administering application and report builds. Refer to the topics Controlling Generations and Reorganizations and Modifying the Generate WFL. The Generate WFL contains absolute upper limits and userspecifiable upper limits on parallel compiles and reorganization tasks. You can tailor these limits within a comments section near the beginning of the Generate WFL file NGEN23/WFL/GENERATE. You can tune the MCP Application Builder to tailor it to your environment, as described in the following points: For a host with multiple CPUs, you can enable the Application Builder option DYNMAKES (default RESET) to set the number of BLD make/compile threads (controlling the number of system and report generates) to the number of enabled host processors. Alternatively, you can set the MAXSYSMAKES/ MAXREPMAKES (default 2 and 2 respectively) options to a reasonable number for the BLD make/compile threads. A very large system generate might exceed these limits for active compiles tasks unless you enable the STRICTCOMPS option. You should set the Application Builder option MAXSYSGEN to at least the number of expected concurrent online application generates. This setting helps prevent any generates being queued by Application Builder because of insufficient workers. (You might also need to increase the MAXWORKERS value.) You should set the Application Builder option MAXREPGEN to at least the number of expected concurrent report generates. This setting helps prevent any generates being queued by Application Builder because of insufficient workers. (You might also need to increase the MAXWORKERS value.) You should enable the Application Builder option RETRYREPS (default RESET) to prevent any single report generate failure from terminating the whole report generate job. Setting this option excludes any failed reports from the generate retry and then reports the excluded ones back to the client at completion. You should enable the Application Builder option DATETIMELOG to ensure that client log messages are time stamped, making any subsequent investigation of the host SUMLOG and so on much easier. In the ICs prior to 1.2.2050 or 2.0.1300, AB Suite did not restart failed generates. For versions older than this, you should enable the Application Builder option ERRORDIAG BUILD to ensure that, in the case of a failed online application BUILD, the client is returned the list of objects that were part of this BUILD. Setting this option enables the user to mark these objects and reinitiate the Build. Part of the process in building and deploying applications to the ClearPath MCP platform includes transferring the source files from the Developer workstation to the MCP server. Use FTP for this task. 28

To ensure that FTP is properly configured, perform the following tasks: Set the FTP options from MARC: NA FTP SERVER_IDLE_LIMIT_DISABLED Check for any potential firewall issues (for example Socket timeout settings for the Builder Client and the FTP connection). Single-Thread Versus Multi-Thread Execution for Build and Deploy Prior to IC 1.2.2050 or IC 2.0.1250, when building for a ClearPath MCP target platform, set the build threads to 1. However, for later ICs or for hot patches after 2.0.1204 in cases where you would like to take advantage of multiple processor systems, you can increase the number of parallel executions of the builder tasks. To do so, modify the configuration file of the Builder, which is named BuilderSettings.xml. You might want to change these tags: NumberOfParallelGenerates, NumberOfReorgTasks, and NumberOfParalleCompiles. You might want to experiment to find the best combination for your environment. Our tests have shown that with a well configured machine, a setting of 4 threads seems to provide the optimum result. Depending on the speed and number of processors that you have in your environment and the other activity on your system, you might need to adjust that number. Tuning and Maintenance of SQL Server The best practices in maintenance of SQL Server are in these topics: General SQL Server Maintenance Periodic Rebuilding of SQL Server Indexes SQL Server Administration Training General SQL Server Maintenance Most users consider regular maintenance of an application database to be a necessary ongoing activity. However, what many users do not realize is that with AB Suite, the model repository is also an application database that is potentially very important to the organization. Therefore, the same activities you would employ in maintaining your production application databases should be done with the SQL Server database as well. You should routinely perform these tasks: Back up your development servers Back up your SQL Server database Export and archive your AB Suite model files and/or backup your Version Control repository Even before switching to AB Suite, many companies have other SQL Server databases. If that is the case, the AB Suite development servers should be included in the normal database backups. You should treat the AB Suite Developer repository with the same level of care you give to any production database. Periodic Rebuilding of SQL Server Indexes Although this is probably not a serious concern under normal circumstances, you should consider periodic maintenance of the SQL Server database to be a good practice to prevent problems in the future. Because of the random distribution of the GUIDs that are used to identify each AB Suite object when a new model is loaded into the repository, the indexes can become very fragmented. If your development process involves a large number of model imports because you are frequently copying models from one repository to another or because you are still doing most of your development in EAE and migrating the changes into AB Suite to build and deploy you should rebuild the SQL Server indexes periodically. This process makes subsequent access to the model more efficient and improves the performance of high input/output (I/O) activities such as system and report Builds. SQL Server Administration Training If your organization did not previously have SQL Server, Unisys strongly recommends that someone in the development team take an introductory course on Windows SQL Server Administration to learn the basic concepts and administration requirements. 29

Impact of Anti-Virus Software on Developer If you have anti-virus software products installed, you might notice a reduction in performance for some general Developer actions such as navigating through the Class View, opening Logic Status and similar activities that access the model. Any anti-virus software can have an impact, but our tests have shown that the McAfee anti-virus software seems to have a greater impact to performance than other common products. Unisys is not suggesting that you run without anti-virus protection; however, you should be aware of its potential impact. If you think you are experiencing performance problems with the Developer, please check the following: You can improve performance to some extent by excluding the database folders from virus scanning. Examples of the folders to exclude are Database folders: Default - C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data. If you want to be more specific, you can exclude individual model database files. Full text catalog folders: Default - C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\FTData SQL Log folders: Default - C:\Program For more details, contact your Unisys AB Suite Support representative and include information related to the antivirus software package and features that you are using. Be sure you are running the latest version of AB Suite Developer. Check that you have the latest version of your anti-virus software. If you are using McAfee anti-virus software, check whether the on-access scan feature is enabled. Enabling this feature can significantly degrade Developer performance. If processes (viewed from Task Manager) continue to consume CPU time after shutting down AB Suite Developer, investigate whether the opening of the Class View or Solution Explorer panes improves when these processes are not running. Check the General Settings being used in Visual Studio. If you are using anything other than Visual C++ Development Settings or Visual C# Development Setting, change the setting to one of these. 30

Additional References You can refer to the AB Suite web page on the Unisys support site for additional information and to the Customer Education web page for courses and workshops. We also offer predefined and custom services. AB Suite Support Site Web Page The Unisys support web site includes documentation for AB Suite that provides several types of documents that might be helpful to you. To access that web page, you need credentials for accessing the support site. In addition to the document libraries for the various releases, you can access documents in these categories: Agile Business Suite HowTo Agile Business Suite Quick Start Tutorials Agile Business Suite White Papers Agile Business Suite Utility Courses and Workshops The following are some of the courses and workshops available through Unisys Customer Education. Agile Business Suite Version Control Workshop (CEL8019) Component Enabler for.net (CEL8020) Agile Business Suite Developer for EAE Users (CEL8022) Getting Started with Agile Business Suite Developer (CES8014)(Self-Study) Agile Business Suite Runtime for the Windows Operating System Administration (CES8016)(Self-Study) Agile Business Suite Runtime for ClearPath MCP Administration (CES8017) (Self-Study) Agile Business Suite Getting Started With Automated Test Tool (CES8041) (Self-study) 31

Unisys Technical Services Several predefined and custom services are available from Unisys technical services around the world, If you are migrating a large application from EAE to AB Suite, consider these services. Unisys AB Suite Implementation Blueprint Service: The Unisys AB Suite Implementation Blueprint Service provides the Client IT Management a roadmap for planning, implementing, and deploying the Client s existing Enterprise Application Environment (EAE) applications and infrastructure to the Agile Business Suite environment. The Service is designed to identify how the AB Suite product suite can best be integrated into the Client s environment, to define the activities that will be required for an actual migration project, to evaluate the impact of the migration, and to determine the approximate costs associated with the migration. The deliverable is the Client agreed-upon implementation blueprint which will include a documented project plan defining the activities to be performed, estimated efforts, and the timescales in each case. EAE Environment Assessment Service: The Enterprise Application Environment Assessment Service helps you prepare to move to the Unisys Agile Business Suite (AB Suite). The deliverables of the Service provide the Client with a view of their current EAE development and deployment environments, a list of hardware and software recommendations, and other requirements to support the Client s migration to AB Suite. The deliverables are designed to help the Client migrate efficiently to AB Suite. Application Model Trial Migration Service: Agile Business Suite Application Model Trial Migration Service is designed to assist the Client with migration of one application from Enterprise Application Environment (EAE) to AB Suite. The Service provides the Client the opportunity to implement a small project, without applying significant resources, to validate a migration strategy. The Service helps the Client understand the risks, costs and the time to deploy a production AB Suite environment. Unisys Corporation will import and build the Client s application to the same runtime platform in use by the Client, which will demonstrate to the Client that the application generates in AB Suite the necessary prerequisite to any Safe Passage testing. Safe Passage is defined as being able to load a valid EAE 3.3 application model file into AB Suite Developer with no errors and without requiring any application changes with the exception of configuration details; generating and deploying to the same platform with AB Suite; and producing the same runtime results with AB Suite as with EAE. Safe Passage Functional Verification Service: The Unisys Safe Passage Functional Verification Service consists in the testing of one EAE 3.3 application, which has been generated for an AB Suite environment, to validate that it produces the same runtime results with AB Suite as with EAE when run on the same platform. The Service provides the consultancy and expertise to develop the test strategy with the Client using best practices, techniques and tools for application functional verification. The deliverables include a Test Results Report and a confirmation that the application functions in accordance with the mutually agreed to testing criteria. 32

Summary and Conclusions When it comes to configuring Windows workstations and Servers for use with AB Suite Developer, the most common advice from the Unisys technical services people who have been working with it for more than two years is recommend they get the fastest processors they can afford and load it up with memory. Increasingly, development is moving from standalone workstations to multiprocessor servers with Terminal Services. This configuration not only reduces the need to upgrade many developer workstations all at one time, it also makes it easier to provide updates to Windows components, including AB Suite ICs, Microsoft security updates, and so on. An added bonus is that working with Terminal Services makes it much easier to support remote workers and out-ofhours workers. Use of a version control product is very important and should become part of the standard build and release process for nearly every AB Suite user whether they have 1 developer or 100 developers. In general, except in the smallest organizations, system builds should always be done from a single, dedicated Developer repository ideally, but not necessarily, using a dedicated Build Server. This practice improves build performance and reduces or eliminates errors caused by conflicts that result from changes that are in process. Our best successes in migrating users from EAE to AB Suite have been with environments in which Unisys Technical Services have been involved in the planning and execution of the project from the very beginning. 33

Notes 34

Notes 35

For more information visit www.unisys.com 2011 Unisys Corporation. All rights reserved. Unisys and the Unisys logo are registered trademarks of Unisys Corporation. All other brands and products referenced herein are acknowledged to be trademarks or registered trademarks of their respective holders. Printed in the United States of America 12/11 11-0057