The word „smart“ in „SmartComponent Library“ indicates that our architects and developers have huge background knowledge of writing ADM2 applications and customizing the ADM2 classes. When modern architecture requirements and user interface flexibility force us to say good bye to the good old ADM2 we have started with the design of the SmartComponent Library framework. The primary design goals were to maintain the developer productivity of an environment like the ADM2 while providing an open and future-proof application architecture with a modern user interface. During the development of the SmartComponent Library not a single line of ADM2 source code has been reused or refactored - but still it shares some key principles with the ADM2 and thus allows for a very seamless migration of standard or customized ADM2 applications.
The SmartComponent Library provides several strategies for modernizing or migrating ADM2 applications. Modernized applications will provide a modern user interface (based on OpenEdge GUI for .NET and for example Infragistics or Telerik .NET Controls) and an open, flexible application architecture following the principles of the OpenEdge Reference Architecture (OERA). This open architecture allows the simple re-use of the migrated business logic in SOA environments (e.g. application to application), with OpenEdge BPM and alternative frontends such as web applications or mobile devices.
Modernized applications can leverage the OpenEdge BPM integration as the provider for automated work steps in a process design (work flow using the migrated business logic to trigger an action in the application) or as a consumer that provides the end user an integrated front end to the BPM processes from within the application.
Option 1: Coexistence of ADM2 and SmartComponent Library
The SmartComponent Library provides adapters that allow sharing the AppServer connection and session information (user, client, company, …) with ADM2 applications. This provides a simple but powerful way of integrating new SmartComponent Library screens and backend logic with an existing ADM2 based application.
It is possible to start the new SmartComponent Library based screens from the existing application menu or turn it around and use the main menu of the SmartComponent Library to start ADM2 based applications.
As the SmartComponent Library provides a similar mechanism to link screens it is also possible to use SmartComponent Library screens to navigate ADM2 screens or vice versa (e.g. using pass-through data links via link and messaging adapters).
Option 2: Re-using ADM2 SmartDataObjects (SDO’s)
The SmartComponent Library has been designed with the ability to connect the frontend seamlessly to a variety of back ends. While our default backend is based on ProDatasets and Business Entity and Data Access classes we provide and maintain the necessary adapters to use ADM2 SmartDataObjects as data providers for the .NET user interface. SmartDataObject data (RowObject temp-table) can be used in grid controls, viewer controls and as a data source for lookup controls. ADM2 SmartDataObjects and Business Entities can be linked to each other in a single screen if required. SmartDataObject based lookups can be used in viewers that retrieve their data from Business Entities or SmartDataObjects and vice versa.
Option 3: Migrating SDO’s to Business Entities
SmartDataObjects provide an interface to a single RowObject temp-table that can be populated from either a single database table or a joined query. The concept of joined temp-tables was implemented in the ADM2 using the SmartBusinessObject which mostly due to its complexness and poor performance hasn’t been widely adopted. In more typical ADM2 applications the linking between multiple temp-tables (linking SmartDataObjects) is done on the user interfaces using datalinks.
Business Entities are built using ProDatasets and provide the ability to join data from multiple tables and provide a similar concept for tracking changes from the user interface (or another consumer). A key benefit is the ability to process multiple changes (from the same table or joined tables) in a single transaction and provide the ability to implement validation rules taking data in more than a single table into account. Another key benefit is the ability to reuse a set of linked temp-tables in multiple screens or from different consumers implementing business rules more on a business document level point of view then on single record only.
Our graphical Business Entity Designer supports the migration of ADM2 SmartDataObjects by being able to import the RowObject schema into it’s a Business Entity model together with the mapping information from the SmartDataObject (in case of field renames, joined SDO query) and the data source information (data base tables). This process can be repeated to import more than a single SmartDataObject into a single Business Entity model allowing the developer to transform joins (datalinks), that in the ADM2 are only realized in the user interface as true data relations, in the Business Entity Design.
During the code generation typical validation routines (RowObjectValidate, <fieldname>Validate, <pre|begin|end|post>TransValidate) are copied into the generated Business Entity and provide a starting point for adjusting the converted source code.
Our graphical Business Entity Designer also provides functionality to exchange the model with Sparx Systems Enterprise Architect to provide a solution for large scale application modeling using UML. For this purpose SmartDataObjects can be imported into the Business Entity Designer and from there be exported to UML. The Business Entity can then be used as an asset in the UML design which later could also be imported back into the Business Entity Designer.
Our BusinessEntities also support object-relational mapping if required, turning the data from temp-tables and ProDatasets into collections of objects instead. This provides an alternative programming model which can be used for writing business logic or processes.
We support the generation of visual components (like viewer components) from our Business Entity Designer. This process can also generate new visual components for the SmartComponent Library from scratch.
We support the ability to migrate an ADM2 SmartDataViewer design (ABL frame layout) to a SmartComponent Library SmartViewer .NET Control and convert the required data bindings from the SmartDataObject RowObject fields to data bindings to the Business Entity columns.
The result of both generation processes can be used in Progress OpenEdge Architect Visual Designer (Progress Developer Studio in OpenEdge 11) for further fine tuning. Alternatively we can also generate dynamic viewer designs that can be customized by the end user at runtime.
Similar options exist for the migration of SmartDataBrowsers.
Option 5: Reuse ADM2 GUI with a new look using the WinKit
An alternative approach to migrate (and modify well tested code) ADM2 applications to the SmartComponent Library is the use of our WinKit (Window Integration Kit) utility. The WinKit was designed to improve the visual appearance of ABL GUI applications using GUI for .NET without requiring a major impact on existing code.
A WinKit modernized application uses the same Infragistics Toolbar or Ribbon Controls, Tab Folders, Grids, etc. with the ABL GUI. The color schema of the remaining ABL GUI widgets will automatically be adjusted to match the modern styles of the .NET Controls. The WinKit can be used with or without the ADM2. When using the WinKit with the ADM2 the integration of the existing application into the ADM2 typically provides faster results. Due to the well-structured design of the ADM2 many of the hooks we need to include into the existing application are actually provided as a customization to the ADM2. Business logic (SmartDataObjects) does not need to be changed at all for this process.
Typical benefits of using the WinKit are the speed of migrationand safety (business logic does not get changed at all and thus does not need to be re-tested) while still providing a huge improvement of the user interface.
The WinKit and the SmartComponent Library share a common foundation code base and have already been used successfully together. The SmartComponent Library would typically be used for screens that require larger modifications which are easier to implement using the new user interface and application architecture – or when the business logic of those screens should also be made accessible to other consumers or BPM processes. The WinKit can be used to lift the overall appearance of the remaining screens during the migration process. This guarantees that throughout the migration process the end users will have the same application appearance (not feeling like using two different applications) throughout the whole application. This allows to quickly deliver an initial modernized version of the application with a new look, feel and increasing end user acceptance.