While there are many applications for a host access solution like Flynet Viewer, the three primary uses are:
Absolutely! Many organizations are struggling with the problems imposed by running HOD as a Java Applet ever since Oracle deprecated support for applets. Even without the deprecation, major browser vendors have removed support for Java embedded in a web page.
We have major customers that have successfully moved from HOD to Flynet Viewer, taking advantage of the smoother, faster installation (well, no installation, really) and the superior integration with other web components. We even support the popular ZipPrint multi-screen printing, with a server-side AutoPrint macro.
Absolutely! Many organizations are struggling with the problems imposed by running BlueZone as a Java Applet or ActiveX Control ever since Oracle deprecated support for Java applets and as Internet Explorer has lost significant market share to Chrome (which doesn't run ActiveX controls). Even without the deprecation, major browser vendors have removed support for Java embedded in a web page and don't support ActiveX. Microsoft Edge, their latest browser doesn't even support ActiveX, making the BlueZone path into the future a dim, unsupported one.
Moving from BlueZone to Flynet Viewer takes advantage of the smoother, faster installation (well, no installation, really) and the superior integration with other web components.
Flynet Viewer pricing is based on a combination of a production server license combined with a concurrent session price. There are no per-seat costs for users, and a special pooled session option can provide high transaction rates with only a few connected sessions. For web service solutions many customer configurations are under $20,000 U.S. while for pure web terminal emulation an entry price under $5000 can serve a large number of casual / infrequent users.
Our template-based application generation currently supports Visual Studio 2017, Visual Studio 2015 and older versions including 2013, 2010, 2008, 2005 and 2003. Visual Studio 2003 and .NET Framework 1.1 were the first generation options for Flynet Studio and since then we have added support for each new version as they became generally available (or soon after).
Our latest support, originally built for .NET 4.0 includes a number of enhancements specifically targeted at this significant release. These include support for web application project types as well as the new web deployment integration starting with VS2010 that makes it much easier to deploy a web service or web UI application to an IIS web server.
For more details see: Flynet Viewer 2010 Introduction
Our template-based application generation currently supports .NET Frameworks 1.1, 2.0, 3.5, 4.0, 4.5, 4.6 and 4.7. .NET Framework 1.1 was the first generation option for Flynet Studio and since then we have added support for each new version as it became generally available (or soon after).
Our latest support, for .NET 4.0 through .NET 4.7, required new assemblies (built specifically targeting 4.0, to enable more performant and stable runtime environments) as well as some crafty installation program updates.
Yes and no. The Flynet Viewer product set does read (and write) screen-based applications that are typically accessed with a terminal emulator by desktop users. Many developers have struggled to interface to these kinds of applications with a variety of tools and technologies over the years.
The differences with Flynet Viewer to older toolsets are too numerous to list in an FAQ, but each and every painful aspect of screenscraping has been addressed in the design, tools and features of both the development and runtime environments.
Many skeptics have been surprised and literally delighted to see the difference Flynet can make in a screen interfacing project, and we hope that you will dig a little deeper before rejecting it based on experiences with other tools.
Flynet Viewer provides a lot of functionality for a .NET shop that is similar to IBM HATS in the delivered functionality, if you mean the ability to upgrade the screen-based user interface to a superior HTML-based user experience while also providing the ability to encapsulate a set of screens and make them accessible through web services.
While IBM HATS may appeal on the surface to a Java/Websphere developer, Flynet will definitely appeal to both .NET and Java developers alike. There are significant feature differences, which we feel makes the Flynet solution far superior to IBM HATS. The training is far less involved and the results are superior.
We have already helped one customer that was frustrated with the usability of OnWeb, and felt that the vendor has sun-setted the product, making the quality of support spotty and any future enhancements unlikely (OnWeb was originally part of Rumba, which was purchased by NetManage and then, in 2008, NetManage was acquired by Micro Focus).
Our customer found the speed of development, flexibility of the generated code and reliability of the runtime to far exceed what they experienced with OnWeb. Despite already owning a full license, they chose to purchase and re-implement their existing web services, as well as creating a number of new web services.
While Flynet solves the user experience aspect of screen application migration, the same features that provide rapid conversion of screens to a superior web user experience (modernization) can also be used when all that is desired is that improved experience.
For some, this would be considered a tactical solution (those anticipating a migration some time in the future), while for others, this is as strategic a solution as they ever would desire.
Since the Flynet approach of converting host screens to fully editable .NET web pages is more productive in total cost of development than any other tool we are aware of, this makes Flynet the winner for tactical or strategic user interface upgrades, regardless of your migration plans.
The TN3270 protocol is fully supported as one of the primary protocols for Flynet, including standard as well as enhanced TN3270 (TN3270E). In addition to the Telnet portion of the 3270 protocol, Flynet also supports LU identifiers, SNA BIND packages and device declarations that are required by many hosts.
All unique attribute characteristics are supported by the Flynet Emulation service as well as the run-time components such as the Flynet Web Terminal Emulator. This includes numeric-only fields and other attributes specific to the 3270 environment.
The TN5250 protocol is fully supported by Flynet Viewer for both the unique characteristics of the screen attributes as well as the OS/400 user interface patterns. For example, the tools and runtime support for Flynet support the standard selectable and editable lists of the AS400 environment known as "subfiles".
In addition, right out of the box, the AS400 menus and function keys will be clickable in the Flynet web terminal emulator, as these are recognized and setup based on the standard patterns of the platform.
Flynet is one of the few screen integration toolsets that offers full support for the challenging environment of character-based VT applications. Even the web-based terminal emulator has dynamic support for VT-based applications, using all DHTML and AJAX (no java or ActiveX terminal emulation black-box plugins).
When generating a Visual Studio solution that is based on a VT application, all screen interactions and navigation is custom generated to support a wide variety of keying scenarios, including auto-skip, types of inter-field enter keys and so on.
With the release of Flynet 2010, a new feature was added to the ASP.NET Web User Interface generator in Flynet Studio.
This option, when activated, creates a custom SharePoint web part Visual Studio project (and solution) that encapsulates the specific screen and field names contained in your Flynet project. When deployed to your SharePoint site(s), the Flynet SharePoint Host Access Web Part then acts as a Flynet container on any SharePoint page you add it to.
For more, see: SharePoint Custom Web Part with Flynet Host Access