Flynet Viewer FAQ

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.

Absolutely not--while Flynet provides our customers exclusive SharePoint features not found in any other screen integration product, the SharePoint support is additive to the features already in Flynet.

The Microsoft ASP.NET-based User Experience transformation and modernization available with the Flynet tools and runtime is easily hosted in a standard IIS application folder, and in fact this is a pre-requisite for integration into a SharePoint site.

Many Flynet customers implemented web-service based host integration with our web service generation capability long before we even started working on the SharePoint support. Actually, one of our best customers used the Flynet web services along with SharePoint to deliver a significant productivity and user experience upgrade (read about it here), without even using the Flynet SharePoint Host Access web part.

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

In our work with customers that have both SharePoint and host access using terminal emulators, we found that in many cases the user business departments were maintaining SharePoint Lists with content needing synchronization with host screen fields.

As a result of this requirement, we implemented a Row Consumer Interface for the Flynet SharePoint Host Access Web Part. When you place a Flynet web part on the same page as a SharePoint List Web Part, a connection between the two can push scripted updated from a SharePoint List Web Part "click action" to the Flynet web part.

For more details see: SharePoint List Web Part Host Access

Our template-based application generation currently supports Visual Studio 2003, Visual Studio 2005, Visual Studio 2008 and Visual Studio 2010. 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, for Visual Studio 2010 includes a number of enhancements specifically targeted at this new, significant release. These include support for web application project types as well as the new web deployment integration in 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 and 4.0. .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, 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 to a Java/Websphere developer, Flynet will definitely appeal to a .NET developer. There are significant feature differences however, which we feel makes the Flynet solution far superior to IBM HATS.

For more, see: Flynet Compared to IBM HATS (Host Access Transformation Services)

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.

One of the greatest aspects of providing a user experience upgrade toolset is that while we are always "stuck" with starting with the old character-based screen applications, the target is always the latest technology that I.T. teams are targeting at any given time.

At this time, Flynet generates fairly tame ASP.NET ASPX pages that use the Forms model for Visual Studio editing, as for the typical developer trying to move a screen to a web page, this model is easier to work with than MVC.

However, the code generation for Flynet is achieved through a well structured set of templates (authored using CodeSmith) and it is our intent to not only provide an MVC/Razor application option but also one for generating true WCF RIA SilverLight applications.

While there are many applications for a host access solution like Flynet Viewer, the three primary uses are: