Topic
23 replies Latest Post - ‏2014-06-06T03:38:33Z by AndrewPaier
JohnT.Reynolds
JohnT.Reynolds
233 Posts
ACCEPTED ANSWER

Pinned topic The value of Coaches over Enternal UIs

‏2011-03-10T16:47:59Z |
Folks who are new to WLE often "hate" coaches.
They're very primitive, and the way that you build them is totally different from the way that you build jsps, etc.

I've been using "Lombardi" since 2006, and I "love" coaches. I fully acknowledge the limitations of the coach designer, but coaches have a huge advantage - they're part of your process application's snapshot - so they get deployed when the process app gets deployed.

In my five-plus years of working with Lombardi I have yet to find a situation where I had to build an external user interface (I have built them for political reasons, but not because I couldn't provide the functionality with Coaches.).
Coaches are nothing but HTML and JavaScript - and with the CustomHTML component I can put any HTML and JavaScript I want on to the Coach. I can invoke any Lombardi system service from my coaches and render the outputs.

Human Services can be exposed as URLs... So once you have that URL, you can put that link on any screen.
Once you have the URL, you can display the Human Service within an iFrame. That means I can display my Task interface in an iFrame of an external screen.

So next time you start thinking about building an external interface, please think again.
Updated on 2012-02-24T03:14:22Z at 2012-02-24T03:14:22Z by sactel
  • FlournoyHenry
    FlournoyHenry
    96 Posts
    ACCEPTED ANSWER

    Re: The value of Coaches over Enternal UIs

    ‏2011-03-10T16:57:20Z  in response to JohnT.Reynolds
    Great topic John, and I agree! I'll add that we must remember, in WLE we're building processes, visibility, and control ... NOT traditional applications. All too often, developers (and users) focus on the traditional application touch points like fancy user interfaces. In this paradigm, we instead focus on the process and the value proposition to the organization. User Interaction should be short and concise touch points in the process, not "do it all" screens. Yes, the coach designer is limited and cumbersome compared to traditional UI development, but the Process is king in this environment, not the screen.
    • kolban
      kolban
      3314 Posts
      ACCEPTED ANSWER

      Re: The value of Coaches over Enternal UIs

      ‏2011-03-10T18:21:43Z  in response to FlournoyHenry
      I can't argue with either of you. Having worked with IBM's predecessor BPM products since the end of the 90s, I have seen an evolution. Originally IBM said that UIs were the remit of "presentation services" and the BPM (as we know it now) was the remit of "process orchestration" and that customer could mix and match their "presentation services" of choice with their "process orchestration" functions with their "data owning functions". With WPS, we originally provided very little in the way of UI construction but instead provided a richness of APIs through EJB, REST, Web Services and JMS. We just wiped our hands (to the most part) for UI construction and said "We provide the glue and the customer is at liberty to choose their own UI technology that they likely have already adopted". We provided samples for WebSphere Portal, JSPs, JSFs, Struts and more. This was early and mid 2000s. By the time we reached the end of the 2000's, customers were being shown (by our as then competitors) UI construction built into the BPM framework. And ... not unsurprisingly, customers liked this. It allowed amazing versatility of UI changes when the process changed ... but ... to my mind ... one of the key factors was that it allowed Business and IT to create "initial" screens in moments without lots of work. IBM tried to address this market change with tighter integration with IBM's Lotus Forms UI technology as well as Mashup widgetry (Business Space/Lotus Mashups) and the integration of Dojo.

      Today I still find many, many customers who have made architectural UI choices for their user community. Some our browser based (Portlets, custom JSPs, custom JSFs, Dojo, jQuery and the like), some are rich UI based with Adobe Flex (and to a lesser extent Microsoft Silverlight) and some are rich client like IBM Expeditor and Adobe AIR.

      I have opinions on Coach UIs as seen in WLE today some paint it in an extremely positive light, some not so much.

      So ... as Flournoy says, WLE is there for BPM development and principles ... and it happens to supply a UI creation technique that will accommodate the majority of use cases ... but there will come times when customers have made investments in "paradigms", "technologies" and have existing UI infrastructures that will have to be leveraged with WLE and then we have the opportunity to leverage those from WLE through its own exposed UI techniques.

      Neil
    • JohnT.Reynolds
      JohnT.Reynolds
      233 Posts
      ACCEPTED ANSWER

      Re: The value of Coaches over Enternal UIs

      ‏2011-03-10T18:33:30Z  in response to FlournoyHenry
      The key to remember is: "How hard will it be to deploy my process application, and how hard will it be for me to deploy the inevitable changes to my process application?"

      BPM is there to support continuous process improvement, and the more difficult you make it to deploy your improvements, the less you have met your goal.
  • PrakashKanchan
    PrakashKanchan
    36 Posts
    ACCEPTED ANSWER

    Re: The value of Coaches over Enternal UIs

    ‏2011-03-11T14:42:45Z  in response to JohnT.Reynolds
    I have to agree. Coaches aren't the best out of box as far as the visual appeal goes - but with a little bit of css there isnt any reason why it cant be decked up.

    I do however, wish that lombardi had a better documented wiki of how to make these customizations. I know the old wiki had some good articles on these, but a lot of them involved making changes to "core" xslts, and jsps - and thats always a mess for upgrades and "support". Things like jquery now offer some visual appeal on top, but changing behavior (like autoforwards, coachlets etc) is still cumbersome.
    • JohnT.Reynolds
      JohnT.Reynolds
      233 Posts
      ACCEPTED ANSWER

      Re: The value of Coaches over Enternal UIs - "place holder coaches"

      ‏2011-03-11T15:03:34Z  in response to PrakashKanchan
      So lets assume that for reasons beyond our control, the client forces us to use "external" UIs - "external" Human Interfaces.

      I always recommend that you build out the process using Coaches first. The Coaches can be very simple, but they have to be functional enough to "move the process along".

      "External" UIs "work" because we're able to use the web api and some other techniques to "Complete a Task". Essentially, the external UI provides the information that must be output from the Task.

      Any Task, whether or not you mark it as an "External" task, can be completed using the web api.

      So... You really need to have a working process with working tasks BEFORE you can even start thinking about implementing the "External" UI.

      The best way to validate that your process is working is to use "place holder" coaches - They allow you to step through all of the process paths. You really must have them, or it will be next to impossible to debug the process - and you really must have the process debugged before you can start building that "External" UI.

      In the past, I have been very sneaky and used this to my advantage to change the client's opinion about Coaches. When I do my early playbacks, I step through the place holder coaches. I use them to discuss the requirements, validate the process, etc.

      When we discover changes to the process... I make the change immediately, and then show them the changes - using the place holder coaches.

      While doing this, I casually mention how easy it is to change the UI and Process together when using Coaches, and I lament how hard it's going to be once we start testing the "External" UIs.

      Amazingly someone from the business will say - "Then why aren't we just using the Coaches" ;-)
    • eddiejm
      eddiejm
      54 Posts
      ACCEPTED ANSWER

      Re: The value of Coaches over Enternal UIs

      ‏2011-03-11T16:21:45Z  in response to PrakashKanchan
      Coaches are a framework - from which you can do some pretty cool stuff (see attached screenshot).
      I did this and some folks would tell you I'm the village idiot.

      We frustrate ourselves assuming that the base Coach should be just what each of us expects it to be.
      Coaches are like buying a box of Lego's to build a working model of the Space Shuttle - it's doable, but you're going to have to work for it.
      This type of UI requires a level of effort no matter what tool you use.

      Some may call this old-school but there is something to be said for HTML, CSS and JS.

      NOTICE: Certified organic old-school. No XSLTs, JSPs, JSFs, or other TLAs and FLAs were used in the manufacturing of this product.
      Stop calling my baby ugly ;)
      • JohnT.Reynolds
        JohnT.Reynolds
        233 Posts
        ACCEPTED ANSWER

        Re: The value of Coaches over Enternal UIs

        ‏2011-03-11T16:34:45Z  in response to eddiejm
        Eddie a village idiot? Crazy as a loon yes, but idiot? No way :-)

        (For those who don't know us, Eddie and I have been comrades in crime since 2006)

        For those who have access to wiki.lombardi.com, you can see some really great community efforts to enhance, extend, and simplify what you can do with the Coach Designer. Very exciting stuff...

        But regardless... Having the ability to fall back on good old HTML and JavaScript is something I would never want to lose. It's that "lowest common denominator" safety net that allows me to get the job done when all else fails.
        • eddiejm
          eddiejm
          54 Posts
          ACCEPTED ANSWER

          Re: The value of Coaches over Enternal UIs

          ‏2011-03-11T16:56:47Z  in response to JohnT.Reynolds
          and we are relatively certain we've hidden the bodies for good ;0

          "For those who have access to wiki.lombardi.com..."
          For those of you who don't - sign up for one of the Level 1 or 2 courses; I'll teach you.

          full disclosure: I do believe Coaches have a flaw; the table-based layout. It amazes me that amidst all the wailing and gnashing of teeth over Coaches, no one ever seems to wail about this.
          • JohnT.Reynolds
            JohnT.Reynolds
            233 Posts
            ACCEPTED ANSWER

            Re: The value of Coaches over Enternal UIs

            ‏2011-03-11T17:03:33Z  in response to eddiejm
            Eddie,

            Your disdain for Table Based Layout is shared by the folks who are working on the Community Coach Designer.

            For those who aren't bored yet...

            The Coach Designer creates an XML definition for the components that you want on your Coach.
            An XSL Transform takes the XML definition and converts it to good old HTML and JavaScript.

            All of the editable controls on your coach end up as fields on an HTML form... The names of those fields are used to bind the values in the form to the variables that you defined back in the Service Modeler.

            It's all pretty brain dead simple... and that's what makes it so easy to extend.

            • You can override the CSS
            • You can add new CSS classes to the controls
            • You can use Custom HTML
            • You can modify the XSL transform on a Coach-By-Coach basis to change the HTML and JavaScript that are generated

            And best of all... Eddie can teach you how to do all of this ;-)
            • JeoffWilks
              JeoffWilks
              29 Posts
              ACCEPTED ANSWER

              Re: The value of Coaches over Enternal UIs

              ‏2011-03-11T17:35:39Z  in response to JohnT.Reynolds
              John, couldn't help but notice the subject "Enternal UIs" ... did you mean External UIs or Eternal UIs? or were you subliminally trying to tell us that they are one and the same? :)
              • JohnT.Reynolds
                JohnT.Reynolds
                233 Posts
                ACCEPTED ANSWER

                Re: The value of Coaches over Enternal UIs

                ‏2011-03-11T17:39:44Z  in response to JeoffWilks
                Jeoff...

                They do seem to live on forever, so I guess they are Eternal UIs ;-)
                • JeoffWilks
                  JeoffWilks
                  29 Posts
                  ACCEPTED ANSWER

                  Re: The value of Coaches over Enternal UIs

                  ‏2011-03-11T18:01:05Z  in response to JohnT.Reynolds
                  I thought you meant eternal as in eternally-in-development.

                  Anyway yes, if you do an external UI (with or without use of the REST API) then you lose one-click deployment of both UI and process (since by definition the UI is external). It adds the same risks as any system-to-system integration -- the compexity of managing an interface between two systems that are evolving separately and may have different deployment schedules, uptime, etc.
                  • JohnT.Reynolds
                    JohnT.Reynolds
                    233 Posts
                    ACCEPTED ANSWER

                    Re: The value of Coaches over Enternal UIs

                    ‏2011-03-11T18:05:11Z  in response to JeoffWilks
                    Thanks Jeoff... I really need to play around with the REST API.

                    One more question... I've heard it described that you use the REST API to manipulate a Coach's UI externally. The Coach is never displayed, but you use the REST API to supply values to fields, push buttons, etc.

                    Is that about right, or did I just dream this?
                    • JeoffWilks
                      JeoffWilks
                      29 Posts
                      ACCEPTED ANSWER

                      Re: The value of Coaches over Enternal UIs

                      ‏2011-03-11T18:33:03Z  in response to JohnT.Reynolds
                      Yes, it is possible to step through coach-based services interactively via the REST API.

                      Go to this page and then find "Step 4: Run the Service":
                      http://wiki.lombardi.com/display/commwiki/Using+REST+API+to+start+and+run+through+an+entire+BPD
  • ddbailie
    ddbailie
    25 Posts
    ACCEPTED ANSWER

    Re: The value of Coaches over Enternal UIs

    ‏2011-03-11T17:25:39Z  in response to JohnT.Reynolds
    Eddie, you beat me to the table based layout point and saved the forum from one of my rants.

    The resulting HTML from the coach designer and the inability to use tools that you would use in other web design efforts are the most frustrating things for me about Coach Designer. I'm excited about future possibilities like a supported REST API that hopefully would make some of those arguments obsolete for the complex layouts. Oh, and let's change the name from "Coach" <- that's always bugged me :)
    • JohnT.Reynolds
      JohnT.Reynolds
      233 Posts
      ACCEPTED ANSWER

      Re: The value of Coaches over Enternal UIs

      ‏2011-03-11T17:38:51Z  in response to ddbailie
      Vince Lombardi is rolling in his grave -- Dave didn't mean it Coach.

      The (Community) REST API is surely a good thing... and often exactly what you need if you have to use an "External" technology.

      My concern with the REST API is that I think you lose "one click deploy".
      If I make a process change that requires a UI change - Don't I have to update the application that is invoking the REST API?

      I'd love for someone whose used the REST API to clear that up for me.
  • sactel
    sactel
    23 Posts
    ACCEPTED ANSWER

    Re: The value of Coaches over Enternal UIs

    ‏2012-02-23T10:59:06Z  in response to JohnT.Reynolds
    Hi,
    I have read through this thread about the value of coaches over external UI, my requirement is the following
    i want to accomplish customised file upload within the framework (lombardi or ibm bpm 7.5). ie all the components (component sending & processing the httpRequest - mulitpart form data ) should be deployed as part of process application or toolkit (no external jsp/servlets).

    I require customised file upload to, say, store the file on the server side or pass this bytestream (file contents) to some other external system, so i can not use the available upload/add document widget control since this will store the document as part of the process database (repos).

    So basically using only coach and services how can one implement this? or put it in a different perspective can i deploy jsp/servlet as part of my "process application" or toolkit ?

    i have also gone thru this link - http://wiki.lombardi.com/display/commwiki/Editing+custom+JSPs+-++a+real-world+example+for+launching+files+stored+on+disk - but this requires creation of external jsp.
    • kolban
      kolban
      3314 Posts
      ACCEPTED ANSWER

      Re: The value of Coaches over Enternal UIs

      ‏2012-02-23T16:22:43Z  in response to sactel
      Hi Sactel,
      Cool question. This was one I got asked a few weeks back by another consumer and am still mulling it over. The bottom line is that there is a REST API that allows us to upload a new attachment or replace an existing attachment. This REST API can be called from a variety of places to attach a new document to a process instance.

      Sounds easy enough ... but there is a "problem" (not so much a problem as a necessity). A UI running in the browser can not access a local file. It is simply not allowed to. The only thing it can do is "post" this file to a remote server using an HTTP POST (a web form). So .. how does THAT relate to our story? The answer is that we can write a Java EE Web app (a WAR) which will receive the data from the browser and then execute the REST APIs (by proxy) to attach the file.

      If you want to work with me on a sample, ping me via private message.

      Neil
      • sactel
        sactel
        23 Posts
        ACCEPTED ANSWER

        Re: The value of Coaches over Enternal UIs

        ‏2012-02-24T03:14:22Z  in response to kolban
        Thanks Niel & Andrew for your reponses. i will like to highlight some observation on these approaches -

        Using the rest api, i am thinking if i have a web application for recieving the file on the server then i can very well use the same web application to store the file on the server or pass the bytestream (file) to the external system (say another DMS system), instead of calling again the Rest API, as there is no need for the process to be direct owner of the attachment.

        Regarding JS/Java option. this seems 2 phased activity and is it done synchronously from user perspective who is uploading the file? so as he can get the response of his upload operation. can you please give some more concrete details?
    • SystemAdmin
      SystemAdmin
      7615 Posts
      ACCEPTED ANSWER

      Re: The value of Coaches over Enternal UIs

      ‏2012-02-23T16:34:37Z  in response to sactel
      You could still use the coach UI. Once the file data is in the DB you can use JS or Java to manipulate it as you need. Either writing it to the server file system or sending to another system as a byte stream. Use JS to Get the file's ID and then hand that to your Java code that does whatever you need. Bundle p that Java code in a jar file and attache to the process app.
  • ldyer
    ldyer
    65 Posts
    ACCEPTED ANSWER

    Re: The value of Coaches over Enternal UIs

    ‏2012-02-23T16:46:31Z  in response to JohnT.Reynolds
    If there's a sample coming out of this thread, let's get it on the BPM Sample Exchange at http://wiki.lombardi.com/display/samples/SAMPLE+EXCHANGE+HOME. This site is the central hub for BPM samples, and you have a very engaged 4000+ practitioner audience there which gives you a lot of benefit...to mention a couple:

    • scale - and track - the adoption of your sample
    • engage other practitioners to help you develop and improve both the sample and the related content
    • automatic versioning of the distributable files

    It's very easy to get your samples out there, but if you need any help, do let me know.

    Cheers,

    • lisa
  • Zerav
    Zerav
    4 Posts
    ACCEPTED ANSWER

    Re: The value of Coaches over Enternal UIs

    ‏2014-06-04T16:49:07Z  in response to JohnT.Reynolds

    Interesting topic.

    We have some project with BPM 7.5.1  that have giant "do-it-all" coaches as requested by the end user.

    The problem here has been that there are mamy lines of HTML generated, thus making the coach extremely heavy.

    Your recommendation would be to tear apart a big coach into several small services to improve the user experience?

     

    • AndrewPaier
      AndrewPaier
      711 Posts
      ACCEPTED ANSWER

      Re: The value of Coaches over Enternal UIs

      ‏2014-06-06T03:38:33Z  in response to Zerav

      First, if you are creating complex UIs, beg your client to upgrade to 8.0 or above as the 7.5 coaches are deprecated and you don't want to invest a ton of man hours in a technology that is already marked as deprecated.  And with things like the Brazos toolkit now available you can create much more sophisticated and modern web UIs without having to do so much hand coding.

      That being said, IMO the absolutely monolithic coach has a  few primary sources IMO -

      1.  Poor decision making.  No one wants to actually articulate what need to happen and push back and limit scope so everything.  Basically no one is empowered to say either "No", or "Not this release" or similar things to limit what you are doing.

      2.  Not a process.  If you get a requirement along the lines of "Any user needs to be able to edit any of the data at any point in the process" then 2 things are true.  First, you will wind up with an very complex and difficult to maintain UI.  Second, you are likely using BPM for application development and either there is no process to implement, or the person gathering the requirements doesn't understand process and is interpreting everything with an application view.  Neither of these is good.

      I could spend hours writing about all the different bad practices you can run into with a large sprawling coach, but the net-net is - don't do it.

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