Migration Uniface Client to Uniface Web

Author: heinz.liener@bluewin.ch (Heinz Liener)

we like to migration our complete uniface forms-application (running client version 9.5/9.7 (original 9.4) to uniface web-service-application (9.7 or 10)... who has experience with such migration?   factsheet or success story available? Is there any migration tool from uniface available? Thank you for any feedbacks

Hi Heinz, there is NO single path to reach your goal. Most part of the process depends from how the current application was written (Standard & Guidelines). In theory if your application is a standard client-server application completely written in Uniface most part (all) of application logic is applied into the the client part; this application logic should be splitted into two layers (DSP and services). IMHO each migration project requires specific planning. Hope it helps you... Gianni

Hi Heinz, the problem is that the web is quite another world than desktop. In principle all that you have processed on the client in the desktop world, you should rewrite in Javascript or move to the server. Probably you have to rewrite your application or use Uniface anywhere. Regards RogerW. 

Hi Heinz, as Gianny and RogerW already mentioned, the most important factor is the state of your CURRENT implementation. If it's a true 3tier with a clear presentation layer, it's not too hard to "parse" the current forms and generate their web counterpart. All it needs is some in-depth knowledge of using the uniface repository and customised tools for the model-driven-software-generation. If you have the more likely situation that you have all your code in the client, it's harder because we have to separate the bussines-logic from presentation and database layer at first and it's not so easy to parse the existing forms to a final model: it needs more manual adjustments in the model prior to generation. Another option is just providing a web presentation adapter "on top" of a slightly modified copy of your current C/S form as a start. Greetings from Frankfurt/Germany, Uli P.S: the task is very similar to a "modernization" of a modal application to a non-modal application using tabwidgets, formcontainer, ...

And I will concur with the others that it does depend on the structure of your current application. I have done what you are talking about, but our c/s app had a pretty clean separation of business logic from UI presentation and so we were able to reuse all of our services with a new tier of USPs that provided a public API. That gave us the freedom to build the front-end in what ever JS framework we wanted, and to change whenever (which we did) a new/better option came along. The thing to recognize is that a web application has different interaction patterns from c/s and so a one-for-one port is often undesirable. Use the opportunity to really look at the user experience.   Andy

Hello Heinz, I just had attended the "Uniface Anywhere Morning Webcast". Perhaps you can join the evening session to see what you already have to bring your C/S app into the browser without adjustments. Greetings from Frankfurt/Germany, Uli Btw. In the past I run a project to parse the formpic etc. and generate a HTML form out of it. But all depends on your current app and what you want to get out of the migration process.

ulrich-merkel said I just had attended the "Uniface Anywhere Morning Webcast". Perhaps you can join the evening session to see what you already have to bring your C/S app into the browser without adjustments.

To join the 4:00 pm CET webinar click here. (Add to your calendar)

Hi Heinz, Just to share the situation we were faced with; Large C/S application - virtually all logic contained in forms, hidden forms and global procs. No funding nor resources to rewrite in order to split logic away from forms / hidden forms / global procs. Needed to get a subset of the C/S application available on the web - asap. Outcome; Current C/S forms are used as the logic container for the web page - ie all business logic is contained in the C/S form. We manage all global variables, extended transactions (think create customer, create order, create order lines, undo it all if user doesn't want to proceed) as pr the C/S world. We only use the fields needed from the form - so that reduces the load too. We had to tweak some things - move some logic from LFLD to VALF etc - however, minor changes compared to completely rewrite the application. It's fast, and scales well too. The web pages are augumented with standard JQUI widgets and JS - all driven by the REST approach. We allow dynamic hiding of fields / values depending on data - as well as using type ahead search (think Google auto search) - all driven via Uniface and small add on services. Since it's a subset of our normal application, we didn't need the full pulldown menus - however, we can handle that as well... So, in short, yes, you can do it. The ideal way is to split the logic out - however, for many organisations that's not feasible time nor cost wise. Some extra work, yes - but in comparison to a rewrite - we believe the approach was worth it. Regards, Knut

hi all answers thank you for all your interesting inputs. we look forward to analyze our c/s application to become a good impression of any migration-efforts we will need. thank you again...  and have a good time Heinz