Topic
  • 21 replies
  • Latest Post - ‏2014-04-17T12:02:19Z by AndrewPaier
kolban
kolban
3322 Posts

Pinned topic Custom UIs for IBM BPM - Dojo or GWT ...?

‏2012-01-11T19:08:11Z |
Folks,
If you were developing a custom UI for IBM BPM, would you choose Dojo or GWT (assuming you are building web based UIs). If neither of these, what would you choose?

I'm starting to become a fan of GWT and would be interested to hear from other IBPM users who are using or considering using GWT.

Neil
Updated on 2013-03-13T19:02:18Z at 2013-03-13T19:02:18Z by kolban
  • AnthonyBpm
    AnthonyBpm
    390 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2012-01-11T19:19:36Z  
    I'd still use a combination of the Coach Designer with Dojo. It's the least intrusive and you can do some pretty decent things with that combination while still working in the confines of the BPM architecture.

    GWT is great, but it is a drastic deviation from the BPM architecture and would be inherently more complex. It also requires a greater amount of expertise as you're entering the world of Java.

    In the end, you have to make a decision that best satisfies the process application requirements while maximizing productivity and efficiency.
  • FlournoyHenry
    FlournoyHenry
    97 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2012-01-11T19:26:37Z  
    What about YUI? Is that still embedded? I seen some neat tricks with on Coaches in the past especially since the libraries were already referenced.
  • AnthonyBpm
    AnthonyBpm
    390 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2012-01-11T19:43:59Z  
    What about YUI? Is that still embedded? I seen some neat tricks with on Coaches in the past especially since the libraries were already referenced.
    YUI is no longer embedded, just Dojo. The 7.2 release notes confirm this.
  • kolban
    kolban
    3322 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2012-01-11T20:35:05Z  
    YUI is no longer embedded, just Dojo. The 7.2 release notes confirm this.
    Ive been seeing a spate of users who like using Coaches for working with Business Analysts to capture what is wanted, desired and for unit testing applications ... but these users have explicitly requested the desire to build custom UI. They ask for this for a variety of reasons such as integration with their existing UI strategy or because they want to provide end user interfaces that need supreme usability factors for eventual end users.

    While I agree that Coach technology will satisfy many, many users, I am solely thinking of the subset of users who do wish to use custom UI technology. I have been studying those available and seem to have come to the conclusion that the primary players are (in no particular order)

    o Dojo
    o Adobe Flex
    o Google GWT

    Although Dojo is the IBM backed/recommended UI technology, the IBPM product appears to be agnostic when it comes to UI creation. As long as REST ability is present, any of the UI frameworks/toolkits/platforms seem to be able to be used. Of the list of Dojo/Flex/GWT, I am pleased to say that I have a little experience of using all of them. GWT is the newest of my UI examinations. I loved Flex (I got a license of FlashBuilder) and what I especially liked was the FlashBuilder development tools. However, a number of folks balk at Flex because it requires either Adobe AIR or Flash Player as a run time environment. Both Dojo and GWT will run natively in the browser. When I started to study GWT, two things immediately struck me:

    1) GWT has a powerful IDE (based on Eclipse) that is a joy to use
    2) GWT uses Java (not JavaScript) as the programmers language to link together logic with the UI. This gets amazingly cross-compiled to JavaScript for deployment/execution. I was nervous about this at first but after a few weeks of using it, not once have I ever had to look at the native JavaScript that was built.

    Using Java over JavaScript seems (to me) to have a huge number of advantages not least of which is type safe data, easy classes, powerful support tooling, rich pre-supplied libraries and programmer familiarity right from the start.

    Another thing I notice is that UIs are "religeous". Folks choose UI package "XYZ" and stand behind that as opposed to package "ABC". I am trying really hard not to get into those religeous wars. Ideally we should have a common UI story that we can all agree to but I'm not seeing that going to happen any time soon.

    I haven't looked at YUI (yet) and am focusing on GWT (for the time being).

    The last users I worked with didn't care what UI framework was used, they want to see "any" custom UI with IBPM and I chose GWT as my weapon of choice. The purpose of this post is to see if anyone else is using GWT. If not, has it been considered? If not, what UI package are you using (and why?)

    Neil
  • TedGaunt
    TedGaunt
    29 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2012-01-12T03:04:10Z  
    • kolban
    • ‏2012-01-11T20:35:05Z
    Ive been seeing a spate of users who like using Coaches for working with Business Analysts to capture what is wanted, desired and for unit testing applications ... but these users have explicitly requested the desire to build custom UI. They ask for this for a variety of reasons such as integration with their existing UI strategy or because they want to provide end user interfaces that need supreme usability factors for eventual end users.

    While I agree that Coach technology will satisfy many, many users, I am solely thinking of the subset of users who do wish to use custom UI technology. I have been studying those available and seem to have come to the conclusion that the primary players are (in no particular order)

    o Dojo
    o Adobe Flex
    o Google GWT

    Although Dojo is the IBM backed/recommended UI technology, the IBPM product appears to be agnostic when it comes to UI creation. As long as REST ability is present, any of the UI frameworks/toolkits/platforms seem to be able to be used. Of the list of Dojo/Flex/GWT, I am pleased to say that I have a little experience of using all of them. GWT is the newest of my UI examinations. I loved Flex (I got a license of FlashBuilder) and what I especially liked was the FlashBuilder development tools. However, a number of folks balk at Flex because it requires either Adobe AIR or Flash Player as a run time environment. Both Dojo and GWT will run natively in the browser. When I started to study GWT, two things immediately struck me:

    1) GWT has a powerful IDE (based on Eclipse) that is a joy to use
    2) GWT uses Java (not JavaScript) as the programmers language to link together logic with the UI. This gets amazingly cross-compiled to JavaScript for deployment/execution. I was nervous about this at first but after a few weeks of using it, not once have I ever had to look at the native JavaScript that was built.

    Using Java over JavaScript seems (to me) to have a huge number of advantages not least of which is type safe data, easy classes, powerful support tooling, rich pre-supplied libraries and programmer familiarity right from the start.

    Another thing I notice is that UIs are "religeous". Folks choose UI package "XYZ" and stand behind that as opposed to package "ABC". I am trying really hard not to get into those religeous wars. Ideally we should have a common UI story that we can all agree to but I'm not seeing that going to happen any time soon.

    I haven't looked at YUI (yet) and am focusing on GWT (for the time being).

    The last users I worked with didn't care what UI framework was used, they want to see "any" custom UI with IBPM and I chose GWT as my weapon of choice. The purpose of this post is to see if anyone else is using GWT. If not, has it been considered? If not, what UI package are you using (and why?)

    Neil
    I've built some rather sweet custom pages inside of Coach Designer using EXT JS, jQuery, jQuery plugins, and also charting controls.

    My favorite is easily EXTJS. This is a low cost commercial product, and the maturity of the models, design, and even their code is genius. I haven't used Dojo, but some of the other controls out there for jQuery (like jqGrid or whatever) are usually fan supported and often I find that the capabilities are pretty rough, the code isn't inspiring, and the doc can be worse. Using EXTJS has taught me how to write javascript using prototypes and OO techniques that I didn't think were possible.

    jQuery for basic stuff is awesome of course, and I tend to use it for most basic manipulation style coding. And there are a bagillion plugins. But the quality or capability of the plugins needs to be carefully evaluated.

    Ted Gaunt
    Lucid Technique, Inc.
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2012-01-12T09:31:39Z  
    • kolban
    • ‏2012-01-11T20:35:05Z
    Ive been seeing a spate of users who like using Coaches for working with Business Analysts to capture what is wanted, desired and for unit testing applications ... but these users have explicitly requested the desire to build custom UI. They ask for this for a variety of reasons such as integration with their existing UI strategy or because they want to provide end user interfaces that need supreme usability factors for eventual end users.

    While I agree that Coach technology will satisfy many, many users, I am solely thinking of the subset of users who do wish to use custom UI technology. I have been studying those available and seem to have come to the conclusion that the primary players are (in no particular order)

    o Dojo
    o Adobe Flex
    o Google GWT

    Although Dojo is the IBM backed/recommended UI technology, the IBPM product appears to be agnostic when it comes to UI creation. As long as REST ability is present, any of the UI frameworks/toolkits/platforms seem to be able to be used. Of the list of Dojo/Flex/GWT, I am pleased to say that I have a little experience of using all of them. GWT is the newest of my UI examinations. I loved Flex (I got a license of FlashBuilder) and what I especially liked was the FlashBuilder development tools. However, a number of folks balk at Flex because it requires either Adobe AIR or Flash Player as a run time environment. Both Dojo and GWT will run natively in the browser. When I started to study GWT, two things immediately struck me:

    1) GWT has a powerful IDE (based on Eclipse) that is a joy to use
    2) GWT uses Java (not JavaScript) as the programmers language to link together logic with the UI. This gets amazingly cross-compiled to JavaScript for deployment/execution. I was nervous about this at first but after a few weeks of using it, not once have I ever had to look at the native JavaScript that was built.

    Using Java over JavaScript seems (to me) to have a huge number of advantages not least of which is type safe data, easy classes, powerful support tooling, rich pre-supplied libraries and programmer familiarity right from the start.

    Another thing I notice is that UIs are "religeous". Folks choose UI package "XYZ" and stand behind that as opposed to package "ABC". I am trying really hard not to get into those religeous wars. Ideally we should have a common UI story that we can all agree to but I'm not seeing that going to happen any time soon.

    I haven't looked at YUI (yet) and am focusing on GWT (for the time being).

    The last users I worked with didn't care what UI framework was used, they want to see "any" custom UI with IBPM and I chose GWT as my weapon of choice. The purpose of this post is to see if anyone else is using GWT. If not, has it been considered? If not, what UI package are you using (and why?)

    Neil
    We use a combination of the Coaches and Dojo, which has done well in most circumstances we have put it in as we style the rest of the page using CSS usually and have had great success in making pages appear as we want using this approach along with using the Dojo controls such as date picker.

    Recently we have started investigating jquery as another team wanted to integrate our coaches into their touchpad technologies using it. I'm still exploring that avenue.

    Using GWT could be an interesting direction and I'd like to see how you get on with it, Neil. I might start investigating it myself.
  • AnthonyBpm
    AnthonyBpm
    390 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2012-01-12T15:29:38Z  
    • kolban
    • ‏2012-01-11T20:35:05Z
    Ive been seeing a spate of users who like using Coaches for working with Business Analysts to capture what is wanted, desired and for unit testing applications ... but these users have explicitly requested the desire to build custom UI. They ask for this for a variety of reasons such as integration with their existing UI strategy or because they want to provide end user interfaces that need supreme usability factors for eventual end users.

    While I agree that Coach technology will satisfy many, many users, I am solely thinking of the subset of users who do wish to use custom UI technology. I have been studying those available and seem to have come to the conclusion that the primary players are (in no particular order)

    o Dojo
    o Adobe Flex
    o Google GWT

    Although Dojo is the IBM backed/recommended UI technology, the IBPM product appears to be agnostic when it comes to UI creation. As long as REST ability is present, any of the UI frameworks/toolkits/platforms seem to be able to be used. Of the list of Dojo/Flex/GWT, I am pleased to say that I have a little experience of using all of them. GWT is the newest of my UI examinations. I loved Flex (I got a license of FlashBuilder) and what I especially liked was the FlashBuilder development tools. However, a number of folks balk at Flex because it requires either Adobe AIR or Flash Player as a run time environment. Both Dojo and GWT will run natively in the browser. When I started to study GWT, two things immediately struck me:

    1) GWT has a powerful IDE (based on Eclipse) that is a joy to use
    2) GWT uses Java (not JavaScript) as the programmers language to link together logic with the UI. This gets amazingly cross-compiled to JavaScript for deployment/execution. I was nervous about this at first but after a few weeks of using it, not once have I ever had to look at the native JavaScript that was built.

    Using Java over JavaScript seems (to me) to have a huge number of advantages not least of which is type safe data, easy classes, powerful support tooling, rich pre-supplied libraries and programmer familiarity right from the start.

    Another thing I notice is that UIs are "religeous". Folks choose UI package "XYZ" and stand behind that as opposed to package "ABC". I am trying really hard not to get into those religeous wars. Ideally we should have a common UI story that we can all agree to but I'm not seeing that going to happen any time soon.

    I haven't looked at YUI (yet) and am focusing on GWT (for the time being).

    The last users I worked with didn't care what UI framework was used, they want to see "any" custom UI with IBPM and I chose GWT as my weapon of choice. The purpose of this post is to see if anyone else is using GWT. If not, has it been considered? If not, what UI package are you using (and why?)

    Neil
    There is no doubt that GWT is a great framework, however, it will impede your ability to deliver quickly and deviates from the customer focus model and interactivity that is inherent with the use of the coach designer. During playback/design sessions are you going to bring up your GWT Java code to show the customers and make changes on the fly? Most likely no :)..

    Staying within the confines of the coach designer is where you'll find maximum efficiency (cost / implementation). Implementing a custom UI in an external framework is definitely supported, but I feel that it should be explored only when there are no other alternatives and the decision to move forward with a complex UI framework should be taken with great care.

    You can use the coach designer and also build a JavaScript framework on top of it using the release of Dojo embedded in the product and custom CSS to generate a pretty stunning and flexible UI.
  • kolban
    kolban
    3322 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2012-01-12T16:39:06Z  
    There is no doubt that GWT is a great framework, however, it will impede your ability to deliver quickly and deviates from the customer focus model and interactivity that is inherent with the use of the coach designer. During playback/design sessions are you going to bring up your GWT Java code to show the customers and make changes on the fly? Most likely no :)..

    Staying within the confines of the coach designer is where you'll find maximum efficiency (cost / implementation). Implementing a custom UI in an external framework is definitely supported, but I feel that it should be explored only when there are no other alternatives and the decision to move forward with a complex UI framework should be taken with great care.

    You can use the coach designer and also build a JavaScript framework on top of it using the release of Dojo embedded in the product and custom CSS to generate a pretty stunning and flexible UI.
    Hi Anthony,
    Great post and I don't disagree with a single word. As you exactly say, "During playback/design sessions are you going to bring up your GWT Java code to show the customers and make changes on the fly?" ... not only no but heck no.

    Where I am coming from is a spate of real-world (back to back) experiences I have been having recently. Users of IBM BPM have been looking at the Coach technology and liking very, very much what they see. However, for a production solution, they have chosen not to use Coach as their end user interface. So, if I may, lets looks at some of the reasons for not using Coach that I seem to be seeing. Maybe I am missing something that will help guide me to better answers.

    The first reason I hear is that the Coach technology doesn't give the richness of flexibility that modern UIs are looking for. Specifically, goodies such as accordion panels, split panes, tab panels, enhanced tables ... and the like.

    The next reason I hear is that Coach is not the UI experience that is used by the rest of the business and UI consistency is important. For example, imagine a company that has 100 insurance clerks dealing with claims. These clerks have a single "dashboard" for working with claims that presents an integrated UI for all the lookups, queries, policies and other items. This UI has had substantial investment because turnover on insurance clerks is high and the UI has to be simple and clear. Bringing in the "Coach" UI into the existing UI framework is perceived as challenging.

    The third reason I hear is that Coach is not "table/phone" friendly.

    However, coming back to your original point, one of the most important strengths of IBM BPM is the ability to have business and IT linked at the hip in terms of the process and this includes UI. Having the UI linked to the process and as easily maintainable as with Coaches is a huge point and I am not trying to belittle that notion in any way. But, if we acknowledge that for some (hopefully small) percentage of IBM BPM projects, Coach isn't going to meet the needs then we need to be able to discuss linkages with other UI technologies ... and it is this last sentence that this thread is about. I don't disagree that Coach should be used wherever and whenever possible ... but when it can't or is chosen not to ... we need to be able to talk about the alternatives.

    And the alternatives are (as I see them) listed in the previous posts. As I literally play with the different UIs, I am finding that (based on what I have seen so far) GWT is resonating with me more than any other browser based UI framework/toolkit.

    One thing that has surprised me in the responses so far are the mentions of jQuery. To be perfectly frank, I have not yet examined that as a platform ... I didn't know it had UI capabilities ... I'll be looking at that next.

    The thing that makes GWT stand out for me (personal/strong opinion) is that I am not working in JavaScript. GWT gives me full access to Java and all the benefits that gives. I realize these last two sentences are religious so feel free to ignore in the scheme of things.

    Neil
  • AnthonyBpm
    AnthonyBpm
    390 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2012-01-12T19:07:57Z  
    • kolban
    • ‏2012-01-12T16:39:06Z
    Hi Anthony,
    Great post and I don't disagree with a single word. As you exactly say, "During playback/design sessions are you going to bring up your GWT Java code to show the customers and make changes on the fly?" ... not only no but heck no.

    Where I am coming from is a spate of real-world (back to back) experiences I have been having recently. Users of IBM BPM have been looking at the Coach technology and liking very, very much what they see. However, for a production solution, they have chosen not to use Coach as their end user interface. So, if I may, lets looks at some of the reasons for not using Coach that I seem to be seeing. Maybe I am missing something that will help guide me to better answers.

    The first reason I hear is that the Coach technology doesn't give the richness of flexibility that modern UIs are looking for. Specifically, goodies such as accordion panels, split panes, tab panels, enhanced tables ... and the like.

    The next reason I hear is that Coach is not the UI experience that is used by the rest of the business and UI consistency is important. For example, imagine a company that has 100 insurance clerks dealing with claims. These clerks have a single "dashboard" for working with claims that presents an integrated UI for all the lookups, queries, policies and other items. This UI has had substantial investment because turnover on insurance clerks is high and the UI has to be simple and clear. Bringing in the "Coach" UI into the existing UI framework is perceived as challenging.

    The third reason I hear is that Coach is not "table/phone" friendly.

    However, coming back to your original point, one of the most important strengths of IBM BPM is the ability to have business and IT linked at the hip in terms of the process and this includes UI. Having the UI linked to the process and as easily maintainable as with Coaches is a huge point and I am not trying to belittle that notion in any way. But, if we acknowledge that for some (hopefully small) percentage of IBM BPM projects, Coach isn't going to meet the needs then we need to be able to discuss linkages with other UI technologies ... and it is this last sentence that this thread is about. I don't disagree that Coach should be used wherever and whenever possible ... but when it can't or is chosen not to ... we need to be able to talk about the alternatives.

    And the alternatives are (as I see them) listed in the previous posts. As I literally play with the different UIs, I am finding that (based on what I have seen so far) GWT is resonating with me more than any other browser based UI framework/toolkit.

    One thing that has surprised me in the responses so far are the mentions of jQuery. To be perfectly frank, I have not yet examined that as a platform ... I didn't know it had UI capabilities ... I'll be looking at that next.

    The thing that makes GWT stand out for me (personal/strong opinion) is that I am not working in JavaScript. GWT gives me full access to Java and all the benefits that gives. I realize these last two sentences are religious so feel free to ignore in the scheme of things.

    Neil
    Hey Neil:

    Thanks. I appreciate this discussion as it has been talked about for quite some time. It's always great to here everyone's opinions on it.

    Anyway, there are situations that call for complete custom UI's and I have definitely had to accomplish this. I guess my only point is that it should be the exception and not the rule.

    re rich experience: You can turn coaches into "rich" client experiences by properly adding a JavaScript framework that transforms the rendered HTML from your coach into what you'd like. For instance, you can turn coach sections into Dojo tabs with some DOM manipulation and CSS. See the attachment. One screenshot shows the coach designer and the other two show how that coach is displayed. This is accomplished by executing some client-side JavaScript that does some DOM manipulation using Dojo. This was built in a way so you can apply it to any coach at any time by making a single function call once the DOM is ready.

    re mobile devices: I believe you are correct, at present, I've heard the coach does not scale well when you throw tablets and smart phones into the fray. I actually have not yet had to worry about this; I should probably consider myself lucky.

    re common user experience: I have successfully adapted coaches to take on the look and feel of the client's general user experience requirements. All-in-all, it wasn't too bad to adapt. It is possible.

    re jquery: JQuery does have UI components, but I don't feel they are as nicely put together as Dojo's. JQuery, from what I've seen, has a much faster selector and DOM manipulation engine. So there are benefits/negatives to each. I primarily used JQuery (3-4 yeas) up until this year since I started exploring Dojo and I haven't really looked back.

    I guess in the end, my opinion is that whatever is decided should be the most beneficial and cost effective to the customer and consumers of the process application.

    -Anthony
  • GaryS
    GaryS
    81 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2012-01-13T05:26:45Z  
    dojo
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2012-01-13T09:22:49Z  
    Hey Neil:

    Thanks. I appreciate this discussion as it has been talked about for quite some time. It's always great to here everyone's opinions on it.

    Anyway, there are situations that call for complete custom UI's and I have definitely had to accomplish this. I guess my only point is that it should be the exception and not the rule.

    re rich experience: You can turn coaches into "rich" client experiences by properly adding a JavaScript framework that transforms the rendered HTML from your coach into what you'd like. For instance, you can turn coach sections into Dojo tabs with some DOM manipulation and CSS. See the attachment. One screenshot shows the coach designer and the other two show how that coach is displayed. This is accomplished by executing some client-side JavaScript that does some DOM manipulation using Dojo. This was built in a way so you can apply it to any coach at any time by making a single function call once the DOM is ready.

    re mobile devices: I believe you are correct, at present, I've heard the coach does not scale well when you throw tablets and smart phones into the fray. I actually have not yet had to worry about this; I should probably consider myself lucky.

    re common user experience: I have successfully adapted coaches to take on the look and feel of the client's general user experience requirements. All-in-all, it wasn't too bad to adapt. It is possible.

    re jquery: JQuery does have UI components, but I don't feel they are as nicely put together as Dojo's. JQuery, from what I've seen, has a much faster selector and DOM manipulation engine. So there are benefits/negatives to each. I primarily used JQuery (3-4 yeas) up until this year since I started exploring Dojo and I haven't really looked back.

    I guess in the end, my opinion is that whatever is decided should be the most beneficial and cost effective to the customer and consumers of the process application.

    -Anthony
    Hi Anthony,
    I've been looking at the screenshots that you attached and we're using the dojo tab control as you show in the screens you attached.

    When the page loads, we see it load the content and then 're-shuffle' the page layout to put it into the tabs - my dojo skills are not all that at the moment and I realise this is a little off topic for this thread, but I wondered if you (or any one else for that matter) had any ideas on why this might be happening?
  • AnthonyBpm
    AnthonyBpm
    390 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2012-01-13T19:51:17Z  
    Hi Anthony,
    I've been looking at the screenshots that you attached and we're using the dojo tab control as you show in the screens you attached.

    When the page loads, we see it load the content and then 're-shuffle' the page layout to put it into the tabs - my dojo skills are not all that at the moment and I realise this is a little off topic for this thread, but I wondered if you (or any one else for that matter) had any ideas on why this might be happening?
    What you're seeing, I think, is a quick glimpse of how the page would look prior to the Dojo 'tabification'. What I typically do is hide the main Dojo tab and then show it after the tab container startup. You could even put a "Loading..." message in place as well.
  • SergeShikov
    SergeShikov
    17 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2013-03-13T10:31:45Z  
    My personal choise is Flex.
  • kolban
    kolban
    3322 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2013-03-13T19:02:18Z  
    My personal choise is Flex.
    I don't disagree. Strangely, just over the last week, I found myself back into Flex. I thought Flex was "dead" but I see it has a new life at Apache and, very importantly, it now supports both Android and iOS.

    Neil
  • RohitC
    RohitC
    4 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2014-04-08T21:31:13Z  

    Hello Neil,

    I am replying to this forum a little too late. Hopefully, I can get some wise advise from the participants. My question is:

    Can I build a complete custom UI (a separate web application) and use the BPM in the background and not use the Process Portal or Coach for that matter?

    Also, how do I pull and present data from other systems (HR data from PeopleSoft, or any existing application data) into the Coach views? This data may not necessarily has to be part of the state-machine, but is needed to be presented on the Coach view for the Human to decide on their action (Approve/Reject, etc.).

    Have you come across requirements like above? What would be the approach?

    thanks

    Rohit

  • AndrewPaier
    AndrewPaier
    832 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2014-04-11T20:56:14Z  
    • RohitC
    • ‏2014-04-08T21:31:13Z

    Hello Neil,

    I am replying to this forum a little too late. Hopefully, I can get some wise advise from the participants. My question is:

    Can I build a complete custom UI (a separate web application) and use the BPM in the background and not use the Process Portal or Coach for that matter?

    Also, how do I pull and present data from other systems (HR data from PeopleSoft, or any existing application data) into the Coach views? This data may not necessarily has to be part of the state-machine, but is needed to be presented on the Coach view for the Human to decide on their action (Approve/Reject, etc.).

    Have you come across requirements like above? What would be the approach?

    thanks

    Rohit

    You have 2 different questions here.  First "Is it possible to use IBM BPM as just an engine and do all your own UI?"  the answer is yes it is possible, but may not be advisable.  I would separate the portal question from the Coach question as they are certainly different concerns.  The Portal - yeah go for it, so what you want/need.  Advantage - when 8.5.5 comes out, your portal will look exactly like it did.  Where as if you customize the OOTB portal you have to re-do all the work.  Disadvantage - Whatever new features ship with 8.5.5, you can't get them in your portal without writing new code.  Only you can determine if which of these is more important.

    Coaches - this is more complex.  I blogged about this here - http://www.bp-3.com/blogs/2014/03/coach-views-vs-custom-ui-development/  It has a more complete answer than I want to re-post on the forum.

    Your 2nd question is about presenting data from other systems.  The question there becomes "Is this data that should be part of the process or is it UI only data?"  If it is UI only and there is, say, a rest API that you can use to access it, then just use the client as your integration.  But if the data is part of the process context, meaning you really need that data later in the process for some server side logic, then you need to pull it into your process using an integration so that you can use it.

    ANDREW PAIER
    VICE PRESIDENT, LABS
    T: 512.600.3239 X 240 / apaier@bp-3.com / @apaier
    BP3 /// www.bp-3.com / Blogs / Twitter

  • dogren@gmail.com
    dogren@gmail.com
    419 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2014-04-11T21:36:25Z  

    You have 2 different questions here.  First "Is it possible to use IBM BPM as just an engine and do all your own UI?"  the answer is yes it is possible, but may not be advisable.  I would separate the portal question from the Coach question as they are certainly different concerns.  The Portal - yeah go for it, so what you want/need.  Advantage - when 8.5.5 comes out, your portal will look exactly like it did.  Where as if you customize the OOTB portal you have to re-do all the work.  Disadvantage - Whatever new features ship with 8.5.5, you can't get them in your portal without writing new code.  Only you can determine if which of these is more important.

    Coaches - this is more complex.  I blogged about this here - http://www.bp-3.com/blogs/2014/03/coach-views-vs-custom-ui-development/  It has a more complete answer than I want to re-post on the forum.

    Your 2nd question is about presenting data from other systems.  The question there becomes "Is this data that should be part of the process or is it UI only data?"  If it is UI only and there is, say, a rest API that you can use to access it, then just use the client as your integration.  But if the data is part of the process context, meaning you really need that data later in the process for some server side logic, then you need to pull it into your process using an integration so that you can use it.

    ANDREW PAIER
    VICE PRESIDENT, LABS
    T: 512.600.3239 X 240 / apaier@bp-3.com / @apaier
    BP3 /// www.bp-3.com / Blogs / Twitter

    I'm glad Andrew bumped this. I had made a mental note to come back to this question when I had more time, but had forgotten. Mostly I'm just going to agree with Andrew, I was specifically going to link to his blog post.

    Where we agree:

    * The portal is fair game. I think people create custom portals far more than they should, but it is a viable option to do so.

    *  Creating user interactions in custom UIs is a tactical decision that depends on what you want to optimize. There are lots of processes I can think of where a handful of activities in the BPD might benefit from a custom UI of some sort.

    Where we probably agree (based on my conversations with Andrew in the past), but it isn't explicit from Andrew's blog post.

    * If you are planning on not using coaches at all it is very likely that you aren't building a process you are building an application. This isn't really so much a technology issue. It is entirely possible to build a process application with an entirely custom UI and I've seen it successfully done once. But, extending the logic of Andrew's blog post a bit, in almost all cases people who have decided to optimize for the characteristics of custom UIs at a strategic level tend to not be working on a project that is a good fit for IBM BPM. I've already rambled on about this on some other threads, so I won't do this again here.

    * IBM BPM is not a state machine. Perhaps I'm reading to much into your comment about "state machine" and "in the background" but I'm hearing "I need a state machine for my application, could I ignore the coaches/reports/optimization/playback methodology and just use IBM BPM as a workflow library". Theoretically, that is possible, but I strongly advise against it. Firstly, BPM as a philosophy demands that the process is at the center. BPM shouldn't "run in the background" and you tend to run against the grain of the platform when you expect it to. Secondly, and perhaps more importantly, BPM is not a state machine and it becomes a leaky abstraction when you expect it to be.

    Why is BPM not a state machine? After all, it manages process state doesn't it?

    * Because it can have multiple states at the same time. When a timer fires or a split happens, for example, you end up with multiple tokens. Not to mention every instance also has a state of its own. And each task. Not to mention the states of things like durable UCAs. The point being that sometimes I see people think I "really just want to track a handful of states: requested, approved, rejected, completed, whatever". And BPM is a lot more nuanced that that and I find people get into trouble when they try to treat BPMN as a simple finite state machine.

    * Because it is inherently asynchronous. I once had an architect try to build something that treated BPM as a state machine. He would have a request in the requested state, mark it as approved in his custom UI, go to the next screen in his UI which would query the BPM system for "what state am I in now?" in order to decide what to display. And BPM would answer "requested". Why? Because BPM is asynchronous and the second screen was querying the system almost immediately. BPM had received the "complete" message in the service engine but the BPMN engine hadn't yet done the work to move the token to the next activity. This architect was pretty dim, so he just added a pause in the second screen before he queried for the state. I hope I don't have to explain why that route only leads to madness. This is also an example of the "BPM demands process to be at the center of the world" assertion I made above.  Process tells you what to do next, and when to do it. When you try to have the UI be the center of the world it ends up causing these types of issues.

    * Because if you just try to use BPM as a finite state machine you are only using 1% of the functionality. Even when technically possible, sooner or later someone wants to know why you are using a >$1000/PVU product as a state machine.

    Just my two cents,

    David

  • kolban
    kolban
    3322 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2014-04-12T04:19:33Z  

    I'm glad Andrew bumped this. I had made a mental note to come back to this question when I had more time, but had forgotten. Mostly I'm just going to agree with Andrew, I was specifically going to link to his blog post.

    Where we agree:

    * The portal is fair game. I think people create custom portals far more than they should, but it is a viable option to do so.

    *  Creating user interactions in custom UIs is a tactical decision that depends on what you want to optimize. There are lots of processes I can think of where a handful of activities in the BPD might benefit from a custom UI of some sort.

    Where we probably agree (based on my conversations with Andrew in the past), but it isn't explicit from Andrew's blog post.

    * If you are planning on not using coaches at all it is very likely that you aren't building a process you are building an application. This isn't really so much a technology issue. It is entirely possible to build a process application with an entirely custom UI and I've seen it successfully done once. But, extending the logic of Andrew's blog post a bit, in almost all cases people who have decided to optimize for the characteristics of custom UIs at a strategic level tend to not be working on a project that is a good fit for IBM BPM. I've already rambled on about this on some other threads, so I won't do this again here.

    * IBM BPM is not a state machine. Perhaps I'm reading to much into your comment about "state machine" and "in the background" but I'm hearing "I need a state machine for my application, could I ignore the coaches/reports/optimization/playback methodology and just use IBM BPM as a workflow library". Theoretically, that is possible, but I strongly advise against it. Firstly, BPM as a philosophy demands that the process is at the center. BPM shouldn't "run in the background" and you tend to run against the grain of the platform when you expect it to. Secondly, and perhaps more importantly, BPM is not a state machine and it becomes a leaky abstraction when you expect it to be.

    Why is BPM not a state machine? After all, it manages process state doesn't it?

    * Because it can have multiple states at the same time. When a timer fires or a split happens, for example, you end up with multiple tokens. Not to mention every instance also has a state of its own. And each task. Not to mention the states of things like durable UCAs. The point being that sometimes I see people think I "really just want to track a handful of states: requested, approved, rejected, completed, whatever". And BPM is a lot more nuanced that that and I find people get into trouble when they try to treat BPMN as a simple finite state machine.

    * Because it is inherently asynchronous. I once had an architect try to build something that treated BPM as a state machine. He would have a request in the requested state, mark it as approved in his custom UI, go to the next screen in his UI which would query the BPM system for "what state am I in now?" in order to decide what to display. And BPM would answer "requested". Why? Because BPM is asynchronous and the second screen was querying the system almost immediately. BPM had received the "complete" message in the service engine but the BPMN engine hadn't yet done the work to move the token to the next activity. This architect was pretty dim, so he just added a pause in the second screen before he queried for the state. I hope I don't have to explain why that route only leads to madness. This is also an example of the "BPM demands process to be at the center of the world" assertion I made above.  Process tells you what to do next, and when to do it. When you try to have the UI be the center of the world it ends up causing these types of issues.

    * Because if you just try to use BPM as a finite state machine you are only using 1% of the functionality. Even when technically possible, sooner or later someone wants to know why you are using a >$1000/PVU product as a state machine.

    Just my two cents,

    David

    Oddly, one of the best vehicle for building a state machine is still IBM BPM (Advanced edition).  This is the delivery vehicle for a first class state machine engine with a top notch state machine development environment.  See the following:

    http://www.ibm.com/developerworks/websphere/library/techarticles/0610_beers/0610_beers.html

    Even though it mentions a now non-existent product (IBM WPS) the function is still very much present and fully supported in IBM BPM Advanced.

    Neil

  • dogren@gmail.com
    dogren@gmail.com
    419 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2014-04-12T12:22:18Z  
    • kolban
    • ‏2014-04-12T04:19:33Z

    Oddly, one of the best vehicle for building a state machine is still IBM BPM (Advanced edition).  This is the delivery vehicle for a first class state machine engine with a top notch state machine development environment.  See the following:

    http://www.ibm.com/developerworks/websphere/library/techarticles/0610_beers/0610_beers.html

    Even though it mentions a now non-existent product (IBM WPS) the function is still very much present and fully supported in IBM BPM Advanced.

    Neil

    Yep. I considered mentioning that. It's a fairly obscure feature, but I have used actually used it once. Never gave me any problems, although I have to say that I we weren't using it for anything fancy.

    The reason I didn't mention it was:

    • I don't think it's what Rohit meant when he was talking about using BPM as a state machine.
    • It really falls into that last point about getting value out of BPM. The state machine of feature of Advanced is an interesting little feature if you are already implementing an Advanced Edition process application. But if you bought IBM BPM Advanced Edition just to use the state machine feature? That would be like buying a brand new iMac because you wanted to light a room. I mean, yes, an iMac does emit light, but that's a really expensive way of buying a lamp.

    David

  • bmruter
    bmruter
    43 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2014-04-15T13:00:41Z  
    • kolban
    • ‏2014-04-12T04:19:33Z

    Oddly, one of the best vehicle for building a state machine is still IBM BPM (Advanced edition).  This is the delivery vehicle for a first class state machine engine with a top notch state machine development environment.  See the following:

    http://www.ibm.com/developerworks/websphere/library/techarticles/0610_beers/0610_beers.html

    Even though it mentions a now non-existent product (IBM WPS) the function is still very much present and fully supported in IBM BPM Advanced.

    Neil

    Keep in mind anything you can do in a state machine you can do in BPEL. (I am guessing it can be accomplished in a BPM as well)   In fact the state machine is really just generating BPEL under the covers,  but you have a lot less control over help well designed that BPEL is.   If your state machine gets complex you will have layers of recursive bpel implementing it under the covers.   Works nice in a POC situation but doesnt scale very well.   It is one of those "nice idea" but not well implemented things,  like selectors if anyone remembers those.   (we havent touched State Machines since WPS 6.0 so I apoligize if this feature has been improved since then).

  • AndrewPaier
    AndrewPaier
    832 Posts

    Re: Custom UIs for IBM BPM - Dojo or GWT ...?

    ‏2014-04-17T12:02:19Z  

    I'm glad Andrew bumped this. I had made a mental note to come back to this question when I had more time, but had forgotten. Mostly I'm just going to agree with Andrew, I was specifically going to link to his blog post.

    Where we agree:

    * The portal is fair game. I think people create custom portals far more than they should, but it is a viable option to do so.

    *  Creating user interactions in custom UIs is a tactical decision that depends on what you want to optimize. There are lots of processes I can think of where a handful of activities in the BPD might benefit from a custom UI of some sort.

    Where we probably agree (based on my conversations with Andrew in the past), but it isn't explicit from Andrew's blog post.

    * If you are planning on not using coaches at all it is very likely that you aren't building a process you are building an application. This isn't really so much a technology issue. It is entirely possible to build a process application with an entirely custom UI and I've seen it successfully done once. But, extending the logic of Andrew's blog post a bit, in almost all cases people who have decided to optimize for the characteristics of custom UIs at a strategic level tend to not be working on a project that is a good fit for IBM BPM. I've already rambled on about this on some other threads, so I won't do this again here.

    * IBM BPM is not a state machine. Perhaps I'm reading to much into your comment about "state machine" and "in the background" but I'm hearing "I need a state machine for my application, could I ignore the coaches/reports/optimization/playback methodology and just use IBM BPM as a workflow library". Theoretically, that is possible, but I strongly advise against it. Firstly, BPM as a philosophy demands that the process is at the center. BPM shouldn't "run in the background" and you tend to run against the grain of the platform when you expect it to. Secondly, and perhaps more importantly, BPM is not a state machine and it becomes a leaky abstraction when you expect it to be.

    Why is BPM not a state machine? After all, it manages process state doesn't it?

    * Because it can have multiple states at the same time. When a timer fires or a split happens, for example, you end up with multiple tokens. Not to mention every instance also has a state of its own. And each task. Not to mention the states of things like durable UCAs. The point being that sometimes I see people think I "really just want to track a handful of states: requested, approved, rejected, completed, whatever". And BPM is a lot more nuanced that that and I find people get into trouble when they try to treat BPMN as a simple finite state machine.

    * Because it is inherently asynchronous. I once had an architect try to build something that treated BPM as a state machine. He would have a request in the requested state, mark it as approved in his custom UI, go to the next screen in his UI which would query the BPM system for "what state am I in now?" in order to decide what to display. And BPM would answer "requested". Why? Because BPM is asynchronous and the second screen was querying the system almost immediately. BPM had received the "complete" message in the service engine but the BPMN engine hadn't yet done the work to move the token to the next activity. This architect was pretty dim, so he just added a pause in the second screen before he queried for the state. I hope I don't have to explain why that route only leads to madness. This is also an example of the "BPM demands process to be at the center of the world" assertion I made above.  Process tells you what to do next, and when to do it. When you try to have the UI be the center of the world it ends up causing these types of issues.

    * Because if you just try to use BPM as a finite state machine you are only using 1% of the functionality. Even when technically possible, sooner or later someone wants to know why you are using a >$1000/PVU product as a state machine.

    Just my two cents,

    David

    Just for the record I agree with everything David said.  I didn't address some of these issues simply because I don't have the same experiences as he does and so have different primary concerns I was addressing.  Thanks for the additional perspective David.

    ANDREW PAIER
    VICE PRESIDENT, LABS
    T: 512.600.3239 X 240 / apaier@bp-3.com / @apaier
    BP3 /// www.bp-3.com / Blogs / Twitter / LinkedIn