Rapid Development Cycle Flynet Viewer's development toolset enables rapid capture of host screen based application data and workflows. Using the captured application metadata, Flynet Viewer's state of the art code generation capabilities create new .NET web services and even whole applications.
Additional transactions can be added at any time simply by recording more portions of the host application and generating additional .NET functionality.
Web Service Generation While Service Oriented Architectures (SOA) based on Web Services open-up a whole new level of flexibility in meeting business requirements, how do you integrate existing applications with the new SOA-based tools? Many tools can consume Web Services, but absolutely NO OTHER PRODUCT can Create Web Services like the new Flynet Viewer Studio.
Our development tools can Record, Map, Design and create a Complete .NET Web Service Suite from your existing Mainframe (3270), iSeries/AS400/i5 (5250) or UNIX/VAX VT100-VT320 terminal-based applications.
With .NET Framework 2.0, you need no other tool to generate, compile and deploy industrial strength web services. But wait, the best feature of this architecture is that a complete Visual Studio Solution is also generated ready for you to open in your choice of Visual Studio 2003 or Visual Studio 2005, to enable Complete Control over the Generated Application.
And there is even more. Our Code generation framework is based on User definable object property extensions and the industry leading CodeSmith Templating technology. The Code generation templates are provided with the installed product ready for a development to tweak and extend to fit the needs of even the largest of project scopes.
Ongoing Access to All Transactions Core business transactions, such as those used in a call center to provide customer service, are typically first built for the customer service reps in the transaction screens they utilize. When using a product like Flynet Viewer, new functionality is available faster by riding on top of the screens used by the core users compared to a tedious parallel implementation using custom code modules developed on the mainframe.
Integration with .NET Development Flynet Viewer is designed as a .NET development tool. It customizes the bridging between existing screen-based applications by generating .NET integration classes. With the existing screens, the new .NET functionality is available far faster than with custom code implementations that have to re-create the already existing workflows represented in the screen based system.
The generated Flynet Viewer assemblies are specifically designed to integrate with the Intellisense of Microsoft Visual Studio, enabling very high developer productivity, as all names are easily visible to developers as they build new applications on top of the old.
"If You Can See It, You Can Use It" When enhancing business processes through new technology such as .NET, the existing users are the best source of "how it works" as well as "how it should work". When building on top of existing screen-based applications, the "how it works" is right there in front of everyone's eyes.
Contrast this with even the best Entity-Relationship Diagrams of relational database models. To the users trying to express design goals, a list of field names linked together with arrows is too abstract. Users want to be able to point to their existing applcation screens and describe how the improvements should work.
With the "See It. Use It." approach to design, the gap between user application domain experts and the development staff is easily bridged using screen images and Flynet Viewer's development toolset.
Avoids Duplication of Effort Integration to mainframe application systems needs to accommodate both the database and business rules. If the mainframe database has available access mechanisms, such as a DB2 to ADO.NET bridge product, you still need to incorporate the business rules. There are design approaches to implementing a data layer that is independent of the user interface, but this is rarely implemented "after the fact" on an existing system due to the expense and high likelihood of regression-based bugs for the existing users.
As long as there are screen-based users accessing transactions on the mainframe, it is more economical to build on top of those same screens than to try to replicate a parallel implementation using custom transactions. Any "technical elegance" is rapidly diminished in value due to the almost complete duplication of effort.
Enables Strategic, Organic Code Migration The Flynet Viewer development methodology captures as much of the application behavior as possible through the existing screens while incorporating design input from users. Using the extensive code generation of the V4 Studio, rapid replication of the user interface as well as the production of a Service Oriented Architecture Web Service catalog is facilitated.
Once a large percentage of the application use has been migrated away from native terminal emulator access to a new .NET-based User Interface, slices of the back-end application can be migrated to the custom code approach, such as new MQSeries transactions replacing the screen-based ones.
Unlike a wholesale conversion of the back-end transactions, the Flynet Viewer approach has minimal risk and a very low relative cost.