Adding Web interface to old Uniface Applications

Hi Yaki

Years ago, we asked ourselves the same question and UnifAce didn't have a "straight ahead" solution back then either.
And the documentation on modernization was (is?) very vague, you're right.

Which I did once as a test.
Duplicated a "form"
Then ran a convert to a server page on the copy.
This gave me a basis to have a look at how it could look.

It works quite well with very simple masks, but when it gets a bit more complicated ...

Ingo

Hi Yaki,

It's a little bit complicated....

In older Uniface applications, a lot of the code is activated through LFLD, NFLD and <DETAIL> triggers.
So, where / how to move those code snippets??  That's a separate discussion...

Older Uniface applications maintains session and state - even through 10 or more forms.
The web is stateless - so you'd have to design and implement a new, temporary, storage mechanism
in case you want to roll back the whole thing (think create new customer as a part of creating a new order),
Simply storing and committing the data for each screen (to their correct tables/entities) isn't really 
what's you'd like to do.  Of course, you could create a 'tidy up' process to deal with that mess...

Unfortunately, there isn't really a 'one-size-fits-all' solution since each application have their own
unique use cases and behavior... 

Sorry that I cannot be of more specific help.

Regards,
Knut

Do you know if when modifying some screens of the Uniface app to be web based while not modifying other screens in the Uniface app - can both of these types of screens be accessed from the same virtual terminal (such as Citrix or Jetro)? 

Why do you need some forms to be web based? Just to show your customer/customers that it's a modern application or to have a more flexible application, considering installation capacities and a better resources utilizing?

If one would later have wanted to make a smooth migration from a Uniface desktop application to a Uniface web-application, every process happening in your program should have been based on services/processes processing on a separate layer/tier.
However, If we would have knew this in the 1990 (or I think we knew), we would still probably not have made our programs enough service based.
I think, that one of the biggest benefits we have got from Uniface, was utilizing the form specific triggers etc., which perhaps somehow lured us to code too much within the form. I think very few Uniface desktop applications have been coded, so that the web-migration would be easy to do. Actually, 15 years ago, we started to program some services that contained our "global parameters" etc., just to make it easier to migrate further to a more tiered application containing state etc. However, with varying results.  
If we have needed a more "layered" installation, we have used Uniface Anywhere to achieve this, which actually is the same as using some other virtual terminals, also considering the license costs etc.

Some people think that the future of the web programming is web-assembly, perhaps with applications reminding more of a desktop application in the browser, perhaps reminding more of a desktop application running in Uniface Anywhere!?

But as Knut said "Sorry that I cannot be of more specific help".

Regards RogerW.

Hi Yaki,

I have too much information in my head to write in a short response, but here are some thoughts:

Many have successfully modernized their Uniface applications to web. In my experience, the effort is much less to modernize using Uniface rather than augmenting with other technologies.

The next/previous/leave field field trigger considerations that some have mentioned normally only apply when moving from green screen applications, and would typically have been done many years ago when moving to desktop. If you are belatedly facing that challenge, I would say that the existence of these triggers and the modeling approach should make it fairly straightforward to change the implementation. See the Business Rules & Validation course for information on using trigger validate instead.

While you can reuse a lot of code, web applications normally have a different user interface/experience, are stateless, and use different techniques.You can make a Uniface application n-tier by moving logic into services, and don't need to write a data layer as Uniface does that for you.

If you aren't familiar with Uniface Dynamic Server Pages, I recommend doing the DSP Web Development learning path to experience how to build a web application (this shows one UI pattern, and will teach you many of the skills you need to build a prototype that matches your needs). You can then look at the other DSP learning modules (and keep an eye out for new ones), and analyze your existing applications and determine the best way to migrate to the target state.

You will need to make some modifications to components to run on the web. For example, if you convert a component, you will need to modify some triggers and move logic that is not fired in the target component type (Unlike Uniface 9, Uniface 10 shows all code to make migration easier, and you will need to change the Component Type property instead of using the Uniface 9 Convert option). Other considerations will include state management, security, and navigation, to name a few. I find that building modeled components (previously called templates) containing common infrastructure code and modifying your components to inherit from those to be a good approach. See the How and when to use Modeled Components course in addition to the web learning path for more information.

Kind Regards,

------------------------------
David Akerman
Principal Solution & Enablement Architect
Rocket Internal - All Brands
------------------------------

Thank you all  for your thoughtful responses. You certainly provide important issues to consider.

@Ingo Stiller wrote:

> It works quite well with very simple masks, but when it gets a bit more complicated ..

Indeed our concern is regarding the more complicated scenarios.

@Knut Dybendahl wrote:

> In older Uniface applications, a lot of the code is activated through LFLD, NFLD and <DETAIL> triggers.
> So, where / how to move those code snippets??  That's a separate discussion...

I'd be happy to learn about the pros and cons of the various alternatives to moving such code.

@Roger Wallin wrote:

>Why do you need some forms to be web based? Just to show your customer/customers that it's a modern application or to have a more flexible application, considering >installation capacities and a better resources utilizing?

A primary reason is that the users are used to web based interfaces and the old Uniface applications feel old and outdated, which creates resistance among users to using these applications.

>If we have needed a more "layered" installation, we have used Uniface Anywhere to achieve this, which actually is the same as using some other virtual terminals, also >considering the license costs etc.

I understand that Uniface Anywhere is a rebranding of GO-Global from Graphon Corporation. Any particular advantages for using it with Uniface applications when compared to other virtual terminal products such as Citrix/Jetro?

@David Akerman, thank you for the in depth explanations and the referrals to the course material. I'm sure they will prove very useful.

Yaki.

A primary reason is that the users are used to web based interfaces and the old Uniface applications feel old and outdated, which creates resistance among users to using these applications.

Thanks Yaki for being honest, and yes I recognise the resistance. However I think the "users" usually are the it-support, perhaps some people in the management and a general ignorance of the web-applications impact on the working comfort.
I have used a lot of Web-applications, both ours and those made by large companies. I haven't seen one that can compete with a desktop-application, usually web-applications are somehow slow and uncomfortable. You can for sure recognise the balancing between service-programming and client-programming, and so the huge cost of making these applications comfortable.
I have for years waited for webassembly, hoping to get something that will make this balancing more easy/natural to achive.
You will also have to balance between low code tools and a more direct use of the web base pillars.
I haven't yet looked so much into web-programming in Uniface, however I have used som "rad-tools"  (Javascript-based) from Microsoft (Silverlight, Lightswitch), which both, despite of their versatility, have been very simply closed down by Microsoft.
I've also seen programming, using more of the ground-pillars of the Web-programming, to which IMHO you need a lot of more resources.

I understand that Uniface Anywhere is a rebranding of GO-Global from Graphon Corporation. Any particular advantages for using it with Uniface applications when compared to other virtual terminal products such as Citrix/Jetro?

I think Anywhere is somehow less expensive (although not at all inexpensive) than Citrix and easier to set up. It's of course also specialised for Uniface.
You can't use GO-Global with Uniface, as it's prevented by Uniface.
There shouldn't be any problems using Anywhere behind Citrix, expect the costs.