I start a new project this summer, consisting in developing a web version of a proprietary desktop ERP.

The main goal of my company is to be able to propose a web version of its ERP, with all advantages it involves (mobility, possibility of selling SaaS versions, modern look and components ...), without losing any business feature. By this, I mean that us developers can't rework the business side of the app. The main goal is to be able to translate same processes into web application.

Business layer of the older version is not directly reusable, since it's really GUI-dependent. Those business process were rewritten as UML diagrams, which will be used as support for us to develop the new app.

The problem I meet is that I don't know how to deal with process that need user interactions. For example :

On validation of a sale order, the validation process checks all products it contains, verifying if there is available stock, and then perform different operations. If there is no stock available, the user is asked if he wants to cancel the order, remove this product or select another one equivalent. It works like a Javascript alert or confirm : current "thread" (ie validation process) is on hold, waiting for user interaction. After user's choice, it finishes dealing with the current product, and then validates the next one, and so on.

How to deal with this kind of processes with a web application ? Is there some framework, design pattern or something else that permits to write this kind of business processes, able to start and hold like that ?

A solution could be to split those business processes into smaller ones. For my example, we would have 2 sub-processes : the first one checks all products and flags the problematic ones. Then the user has a screen to decide what to do on flagged products, and validates. At this moment we are sure all products are OK, we can start the second sub-process to perform the others operations.

The problem with it is that even if it's pretty simple on this example, it can be really more complicated. Some process have a lot of users interactions like this one, and then could be splitted into 10 subparts. Like I earlier precised, we don't want to modify or rethink business process, to be sure that we lose nothing or introduce new business bugs.

Does someone has an experience about it ? Do you know some way to deal with this kind of desktop-to-web developments ?

EDIT 15/07/14

There was some misunderstanding about this post, surely related to my poor english expression and vocabulary.

To summarize the problem :

I got a bunch of business workflows described into UML diagrams. They comes from a huge 30-year-old CAMM (production management ERP). The project is to redevelop this application under Java web environment. The main point is that some of those workflows are user-dependent, since, in the middle of the processing, they need a user-interaction. Because web applications are based on a client-server architecture, I don't know how to port them. Reworking/rethinking these workflows is not an option, because it would be too much time-consuming. I need a way to simulate a desktop application on a web app, like Wt, but for Java (i'm not talking about UI but about how to develop workflows ), or to define rules to make those user-dependent workflows web-compatibles.

  • 8
    It sounds like you're going to write a major web project, while not knowing much about the web. You should seek out consultancy from web-related professionals. Jul 10, 2014 at 15:43
  • @FlorianMargaine Thanks for your attention, but what makes you say that I don't know much about the web ?
    – OlivierH
    Jul 10, 2014 at 15:44
  • 1
    Perhaps consider using Wt, at least if your old ERP is coded in C++ .... (Wt would look familiar if you know Qt). Jul 10, 2014 at 15:46
  • 1
    The fact that you seem to have so much trouble with implementing a simple workflow through a web application (plus mixing the concept of "threads" in) is a pretty red flag indicating that you should get more web expertise. You get a data structure to represent the current state and put it in the session. You provide operations to build/operate the structure. You operate the structure with plain HTML or Ajax or REST or other WS.
    – SJuan76
    Jul 10, 2014 at 16:44
  • 1
    hm mmm, sounds like its going to turn into one of "those" enterprise Java applications users know and love. You can write a "single page app" using websockets and angularjs, but my advice is to really consider what the usability will be to make this a success - parroting the existing desktop GUI paradigm will need to be tempered by some practical considerations of web tech and expectiations.
    – gbjbaanb
    Jul 15, 2014 at 14:17

6 Answers 6


Your primary difficulties I feel are that you have a mismatch between a very linear and custom workflow in an older application that do not coincide with the user interaction workflows that are common on the web.

Web applications that interact with a server application that contain the business logic communicate in a Request/Response messaging style. The client browser and the server running an application that has the business logic are separate processes. The client requests a resource (html page, jpg image, JSON data, etc...) and the server provides that resource in an inherently stateless way. This is a much different paradigm from your self contained desktop application that has a concept of global state for a users session. The users session in a desktop application lives and dies by the running process on the workstation.

So basically there are two ways you can handle the maintenance of state in a web application that always has a client/server relationship.

Server Centric

A server centric web application will maintain stateful information for an individual user's session. They do this typically by serving a session cookie once the user is authenticated. The client application (browser) will include its unique session token with each request which allows the server to retrieve stateful information about the clients state from the last time they received a request for this client.

Further the server will contain most if not all of the business logic behind performing actions that the typical business user will want to achieve, actions that have real business value. This is not to be confused with presentation logic which is most client side code (Eg. Javascript) that performs user interface interaction like hiding a particular menu in a form if a specific checkbox has been checked.

Client Centric

While you might have a server to maintain authentication of a user and maintaing an active session, you could use a client side scripting framework (Eg. Javascript framework like AngularJS to perform most if not all of the business logic operations and presentation logic operations. The advantages of this model are that you can program your web application in much the same way as one might program a desktop application. Client state will live and die by the browser navigation to the current page in much the same way that it will live and die on the running process of a desktop application. For communication with a database you can expose stateless webservices on the server that can proxy for a database.

Some important considerations with this approach are that users on client browsers have the ability to modify or change how Javascript can behave which might be potentially dangerous and introduce unknown exception cases to your application. It is highly recommended that if this approach is taken that great care should be taken on interactions with servers to sanitize inputs and validate all data going back and forth.


In summary, the application you specified is very old. It sounds like you are making the right choice in capturing the current workflows and trying to assess what the user needs are. The next step would be to try and follow Agile principles and capture business value in user stories. I would start on clean slate and try to discover other means and workflows that can also attain the same business value captured in the user stories. This application is so old that it was likely limited by the technology of its day to where technical constraints influenced the user workflows in a negative or archaic way. Basically there are probably better ways, more intuitive workflows and user interfaces that the business can use that will also achieve the same end goals.

  • First of all, thanks for this detailed answer, you have well understood my issue. To detail a bit more, this application were actively maintained during its 30 years of existence, and was several times "rewritten". The last version uses Borland VCL and is pretty "modern" in its presentation. As I said, rethinking all workflows to adapt them to a server/client architecture would be a really huge job, except if we can find a way to automate the conversion process (ie apply exact rules on all workflows to make them web-comptatible)
    – OlivierH
    Jul 15, 2014 at 9:49
  • We could in the future make this work of modernization, but for now I try to find a way to be able to port those workflows as is in a web application. @BasileStarynkevitch comment on my question could be a solution : using websockets in, as you said, a client-centric application. But, new point, we have to use Java ecosystem to develop the whole application. Does anyone know a framework or design pattern to "emulate" a desktop-application on web, like Basile's Wt seems to do ?
    – OlivierH
    Jul 15, 2014 at 9:52

Read up on asynchronous programming

It sounds like your original desktop app was tightly coupled with the GUI with functions not continuing until user chooses decisions from popups.

The web, and many GUI frameworks, just don't work like this - all operations that may require user input have to provide a delegate/callback so that processing can continue.

It's really not that bad, but a massive change from your current design. IMO it's worth your time to break down your current design to support asynchronous programming, regardless of Web or GUI toolkit.

  • As I said, reworking on the whole business code is not possible, it would take years, with the risks of breaking something.
    – OlivierH
    Jul 17, 2014 at 7:29

This http://www.unigui.com/ seems relevant. This seems also close https://forums.embarcadero.com/thread.jspa?messageID=510208&tstart=0. I guess your old "business layer" code is written with Borland tools, either C++ or Delphi?

Some decade ago I was porting lots of legacy code from 16bit DOS (Turbo Pascal) to 16bit DPMI (Borland Pascal) and to 32bit Windows (Borland Delphi). In order to port the DOS part as-is without breaking anything (rewriting the code was not an option, just small refactorings) first thing I had to do was to create a "DOS terminal emulator" placed as a component inside a Windows GUI surrounded with 32bit Win32 API and new Windows components etc. Though it seems different, the way DOS application works with user input through modal dialogs etc. is totally different from how Windows event queues work. The emulator arranged things by running the DOS emulator in separate thread - all user I/O functions redirected to the emulation layer which in turn suspended the DOS thread when waiting for an Windows event. The DOS code and its logic was not changed (broken) at all.

In your case you can also get out gracefully by first creating(using) an emulator like JSC C# → JavaScript http://jsc.sourceforge.net/examples/web/CardGames/fx.FreeCell.htm. Once you can run your application "in the browser" you can add the required advantages ("..mobility, possibility of selling SaaS versions, modern look and components ...") one by one

I don't know which technology would be best suited for your legacy server-side language (the GUI-dependent business layer). But the running in the browser technology is already here, building on asm.js as the web processor, see e.g. https://isocpp.org/blog/2013/03/cpp-to-javascript or quite long list of tools that can be used to convert legacy code to be run in the browser at https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS


Disclaimer: I am not a super experienced web developer.

I believe that javascript/the client side of web apps are not usually written this way, as no matter what, in most browsers all js code is run in one thread. However, you can simulate this behavior, with something like this (I have never used it, it's just what I found), to pause a thread (pseudocode):

var stuffIsDone = false

doInAnotherThread(function () {
    // blah blah blah, do stuff, load purchase, talk to server, whatever

    // ...
    stuffIsDone = true

doInAnotherThread(function () {
    while (!stuffIsDone) {} // Do nothing until stuff is done

    // stuff has been done, do whatever
  • Thanks for this link, what a great thing to avoid the use of web workers. I've never heard about it. But here, the purpose of my question is specifically technical, it's more about how to translate old desktop app's tightly GUI-coupled business code into a webapp, without modifying this business code.
    – OlivierH
    Jul 17, 2014 at 8:08
  • JavaScript is single-threaded, you cannot create a second thread to do things in.
    – flup
    Jul 20, 2014 at 17:47
  • Yes, but that library simulates it.
    – Ari Porad
    Jul 20, 2014 at 21:10
  > Reworking/rethinking these workflows is not an option

I am afraid you have to add additional states in your workflow, every time the old workflow asks for a user-decision without changing the base workflow.

example in old system:

customer adds products to basket
checkout: customer decides to buy the content of the basket
system does the verifification
    order article is out of stock
        messagebox: "do you want to (a) cancel the order, (b) remove this product or (c) select another one equivalent"?
            (a) ...
            (b) ...
            (c) ...

so instead of showing the messagebox the intermediate-workflowstate: "One or more articles are out of stock is reached."

alternatively you can introduce the intermediate-workflowstate "order can not be processed" with additional infos for those items that have problems.

in a classical web app the customer is redirected to basket-overview-page where errormessages are displayed next to the order-item that has problems.

  • Yep, that's exactly what i thought in the first place, your solution is quite the same as the splitting i talked about in my question. Unfortunately, this would be too much work too. Imagine thousand of workflows like the one you took as example, on average more complicated than that. Some could have 10 or 20 intermediate states : it would be a huge work, and there would be an high probability that we introduce lots of bugs.
    – OlivierH
    Jul 17, 2014 at 8:58
  • @OlivierH Rewriting complex software is well... a complex undertaking. If you detail out the high level tasks and provide high level estimates you might be able to use that as leverage to convince your boss to hire more people.
    – maple_shaft
    Jul 23, 2014 at 9:33

@JBRWilkinson is right, basically.

Having a web client front end and a web server backend is a highly asynchronously thing by definition. Especially when callbacks come into play to dynamically load data or verify things, etc.

But you don't have to rewrite the whole app. You don't need to rewrite the workflow either. You "only" have to work on those parts that deal with the UI in any way. I write "only", because this can be still painful enough, especially when all the logic is tied into the GUI forms. Been there, done that.

We have made good experiences through this process by pulling out UI code into shared code parts, abstracting the UI away. Thos code parts are used from both the Desktop GUI and the web backend. While the GUI still uses controls etc. as usual, the web backend dynamically renders pages or delivers JSON to the client based on those information. The client consists of a good portion of script code to control the web UI.

Was quite a bit of work and took some serious refactoring to do that transition, but it was worth it. And you learn a lot about good and bad software design along the way, I can tell you that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.