Topic
  • 9 replies
  • Latest Post - ‏2012-11-16T11:20:25Z by rhakaro
rhakaro
rhakaro
24 Posts

Pinned topic Show real Progress Bar in long time process

‏2012-11-13T15:36:47Z |
Hi all!

I´m going crazy trying to include a progress bar during a long time process execution.

I can display a waiting page, a spinning wheel and so on, but I cannot find the way to put a real progress bar that inform the user about the percent to finish.

To be more exhaustive, I have a button that calls a method that insert lots of info on the DB. During this process, I am updating a variable with info about the progress (Imported 3 users from 1500, Imported 4 users from 1500, ...), and would be fantastic to show this info to the user instaed a spinning wheel, using for example a Timed Action builder in this case.

I try everything. Developing a thread seems to give good results, but inside it I cannot use the webAppAccess object, so I cannot go this way.

Anybody knows how can I do that?

THank you very much, best regards.
Updated on 2012-11-16T11:20:25Z at 2012-11-16T11:20:25Z by rhakaro
  • SystemAdmin
    SystemAdmin
    9029 Posts

    Re: Show real Progress Bar in long time process

    ‏2012-11-13T17:20:36Z  
    I haven't tried this, but an idea: store progress in a Variable as you're already doing (WEF Variables are session scoped by default unless you use another builder to limit the scope). Then, use AJAX techniques and a JavaScript framework (jQuery or Dojo) to periodically fetch the value from the the server and update the progress bar accordingly. This approach isn't live time, but it may be good enough.
  • rhakaro
    rhakaro
    24 Posts

    Re: Show real Progress Bar in long time process

    ‏2012-11-13T17:25:17Z  
    Hi Sam, thanks for answer.

    I thought that and try it, but I couldn´t make it works. When I click the button, the long time method begins and it seems that I cannot do anything more until it finish, like refresh the info in the page.

    Best regards.
  • SystemAdmin
    SystemAdmin
    9029 Posts

    Re: Show real Progress Bar in long time process

    ‏2012-11-13T20:20:15Z  
    • rhakaro
    • ‏2012-11-13T17:25:17Z
    Hi Sam, thanks for answer.

    I thought that and try it, but I couldn´t make it works. When I click the button, the long time method begins and it seems that I cannot do anything more until it finish, like refresh the info in the page.

    Best regards.
    I'm creating a small sample. Nearly done, but I have other responsibilities in which to attend. Give me a day or so.
  • rhakaro
    rhakaro
    24 Posts

    Re: Show real Progress Bar in long time process

    ‏2012-11-14T07:44:18Z  
    I'm creating a small sample. Nearly done, but I have other responsibilities in which to attend. Give me a day or so.
    Thank you very much Sam, I´ll wait for it!
  • mburati
    mburati
    2568 Posts

    Re: Show real Progress Bar in long time process

    ‏2012-11-14T16:09:08Z  
    • rhakaro
    • ‏2012-11-14T07:44:18Z
    Thank you very much Sam, I´ll wait for it!
    Thanks for helping out here Sam!

    In the meantime, I do want to point out that it's usually not a good idea to execute long running tasks directly in an http servlet or portlet request, as http requests are usually designed for fairly quick turnaround. The browser may not want to wait for the request to complete and you may be using up one of the server's connection threads from its connection thread pool during that time etc. It's also not a good idea to spawn threads from an http servlet or portlet request (I believe the j2ee spec discourages it and in some cases may prevent it).

    If it's a fairly long running task, then it may be better to do it out of band of the http request, such as via a WebSphere worker object (via straight Java or EJB/MDB) kicked off from a WEF action or via other backend task initiated by an action in the WEF app, but which runs out of band of the initial http request itself. That backend worker could then have a method on it that allows callers to retrieve the progress status, which you could check via Timed Action if desired.

    I hope that info helps,
    ..Mike Burati
    http://www-10.lotus.com/ldd/pfwiki.nsf/
    The postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM.
  • SystemAdmin
    SystemAdmin
    9029 Posts

    Re: Show real Progress Bar in long time process

    ‏2012-11-14T19:45:10Z  
    • rhakaro
    • ‏2012-11-14T07:44:18Z
    Thank you very much Sam, I´ll wait for it!
    Alas, after talking with colleagues, this is a bit more complex than I initially thought. The idea I originally had in mind was flawed. :-) Originally I thought about firing an AJAX GET request to a long server side action (which would do long work and update a session variable along the way) and immediately begin firing period AJAX requests to get the current progress as a number. However, in Firefox, the second ajax request blocks until the first one is complete.

    However, one approach is using one of the "Reverse AJAX" techniques, each of which have important pros and cons. One in particular is the "Hidden iFrame" technique, described in this article http://lchandara.wordpress.com/2012/03/06/comet-programming-the-hidden-iframe-technique/, which I thought was interesting because it has the advantage of being supported by any browser that supports iFrames. Upon a cursory glance, it also appears this technique might work with Web Experience Factory, since you can use the webAppAccess API to get the HttpServletResponse to set appropriate headers (Transfer-Encoding: Chunked) and periodically send back executable JavaScript code that is picked up by an iFrame.

    Without having tried it yet, I was thinking that a form submit would call an LJO method in your model. After setting headers to indicate chunking, the method would progmatically use webAppAccess to invoke data services (for example SQL Call builders in your model) and would also periodically chunk back Javascript (containing percent complete) which the iFrame would pick up and use to set a progress indicator. For example, after invoking each of four SQL Call builders, just like in the aforementioned article, you could send back <script type=’text/javascript’>parent.updateCount(‘” . percentComplete . ”‘)</script> which the iFrame would use to call a local updateCount JavaScript method to change a progress indicator.

    This is what I plan to try, but in the meantime I encourage you to look into this technique or perhaps a better one, since my time to do samples is limited. There are many approaches to doing this. Some are complex to configure; some have side effects you don't want; others don't work with your tooling such as Web Experience Factory (for example, there's a new HTML5 features called WebSockets, but the server side portion wouldn't currently work with WEF)

    There is a really good three part series on Reverse AJAX techniques here, which gave me the idea of trying the Hidden iFrame technique:
    http://www.ibm.com/developerworks/web/library/wa-reverseajax1/index.html

    Let us know how it goes and if I can get a sample done in a timely manner, I'll post here.

    Sam

    Opinions and thoughts my own, not necessarily IBM's.
  • rhakaro
    rhakaro
    24 Posts

    Re: Show real Progress Bar in long time process

    ‏2012-11-15T10:18:52Z  
    Alas, after talking with colleagues, this is a bit more complex than I initially thought. The idea I originally had in mind was flawed. :-) Originally I thought about firing an AJAX GET request to a long server side action (which would do long work and update a session variable along the way) and immediately begin firing period AJAX requests to get the current progress as a number. However, in Firefox, the second ajax request blocks until the first one is complete.

    However, one approach is using one of the "Reverse AJAX" techniques, each of which have important pros and cons. One in particular is the "Hidden iFrame" technique, described in this article http://lchandara.wordpress.com/2012/03/06/comet-programming-the-hidden-iframe-technique/, which I thought was interesting because it has the advantage of being supported by any browser that supports iFrames. Upon a cursory glance, it also appears this technique might work with Web Experience Factory, since you can use the webAppAccess API to get the HttpServletResponse to set appropriate headers (Transfer-Encoding: Chunked) and periodically send back executable JavaScript code that is picked up by an iFrame.

    Without having tried it yet, I was thinking that a form submit would call an LJO method in your model. After setting headers to indicate chunking, the method would progmatically use webAppAccess to invoke data services (for example SQL Call builders in your model) and would also periodically chunk back Javascript (containing percent complete) which the iFrame would pick up and use to set a progress indicator. For example, after invoking each of four SQL Call builders, just like in the aforementioned article, you could send back <script type=’text/javascript’>parent.updateCount(‘” . percentComplete . ”‘)</script> which the iFrame would use to call a local updateCount JavaScript method to change a progress indicator.

    This is what I plan to try, but in the meantime I encourage you to look into this technique or perhaps a better one, since my time to do samples is limited. There are many approaches to doing this. Some are complex to configure; some have side effects you don't want; others don't work with your tooling such as Web Experience Factory (for example, there's a new HTML5 features called WebSockets, but the server side portion wouldn't currently work with WEF)

    There is a really good three part series on Reverse AJAX techniques here, which gave me the idea of trying the Hidden iFrame technique:
    http://www.ibm.com/developerworks/web/library/wa-reverseajax1/index.html

    Let us know how it goes and if I can get a sample done in a timely manner, I'll post here.

    Sam

    Opinions and thoughts my own, not necessarily IBM's.
    Hi mburati and Sam,

    Thank you very much. Thinking about mburati´s post, I´m going to cut the long time process in two or three parts for the moment, showing screens to the user reporting about the operations are being executing.

    The solution that you propose, Sam, are very interesting and I will try it using a blank model and simulating a long process with a loop.

    When I have more info, I´ll post it here.

    Best regards!
  • SystemAdmin
    SystemAdmin
    9029 Posts

    Re: Show real Progress Bar in long time process

    ‏2012-11-15T14:48:43Z  
    • rhakaro
    • ‏2012-11-15T10:18:52Z
    Hi mburati and Sam,

    Thank you very much. Thinking about mburati´s post, I´m going to cut the long time process in two or three parts for the moment, showing screens to the user reporting about the operations are being executing.

    The solution that you propose, Sam, are very interesting and I will try it using a blank model and simulating a long process with a loop.

    When I have more info, I´ll post it here.

    Best regards!
    Breaking the screens and process apart and giving the user feedback sounds like the right approach.

    Also, I ran across this, which you might want to look at:

    Leveraging Reverse AJAX in IBM WebSphere Portal 7.0 using Dojo CometD and Web messaging service
    http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Leveraging_Reverse_AJAX_in_IBM_WebSphere_Portal_7.0_using_Dojo_CometD_and_Web_messaging_service

    It looks like a complex configuration, but might be worth it depending on your requirements. And it appears you can integrate this approach with Web Experience Factory applications.

    I got the much-simpler-to-configure "Forever iFrames" (aka: "Hidden iFrame") Reverse AJAX approach to work with a standalone WEF application and it works well. During the long server side process I send back executable Javascript to an iFrame which in turn updatss a jQuery progress bar on the page (see attached screenshot). However, when I run it as a portlet, it breaks. I plan to continue working on it on the side and perhaps publish it on the wiki.

    Like mburati mentioned, web transactions are supposed to be fast. But I can see use cases where you want to show a progress bar. And like I mentioned, each Reverse AJAX technique has advantages and disadvantages.

    Sam

    My postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM.
  • rhakaro
    rhakaro
    24 Posts

    Re: Show real Progress Bar in long time process

    ‏2012-11-16T11:20:25Z  
    Breaking the screens and process apart and giving the user feedback sounds like the right approach.

    Also, I ran across this, which you might want to look at:

    Leveraging Reverse AJAX in IBM WebSphere Portal 7.0 using Dojo CometD and Web messaging service
    http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Leveraging_Reverse_AJAX_in_IBM_WebSphere_Portal_7.0_using_Dojo_CometD_and_Web_messaging_service

    It looks like a complex configuration, but might be worth it depending on your requirements. And it appears you can integrate this approach with Web Experience Factory applications.

    I got the much-simpler-to-configure "Forever iFrames" (aka: "Hidden iFrame") Reverse AJAX approach to work with a standalone WEF application and it works well. During the long server side process I send back executable Javascript to an iFrame which in turn updatss a jQuery progress bar on the page (see attached screenshot). However, when I run it as a portlet, it breaks. I plan to continue working on it on the side and perhaps publish it on the wiki.

    Like mburati mentioned, web transactions are supposed to be fast. But I can see use cases where you want to show a progress bar. And like I mentioned, each Reverse AJAX technique has advantages and disadvantages.

    Sam

    My postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM.
    Ok Sam, it seems to be exactly what I was looking for. Thanks for the link, it is very explicit about the development process.

    I will try and give you the update.

    Best Regards.