Pinned topic The value of Coaches over Enternal UIs
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.).
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.
FlournoyHenry 270003UB3596 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2011-03-10T16:57:20Z in response to JohnT.ReynoldsGreat 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 10000004463314 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2011-03-10T18:21:43Z in response to FlournoyHenryI 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.
Re: The value of Coaches over Enternal UIs2011-03-10T18:33:30Z in response to FlournoyHenryThe 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 270003AQVN36 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2011-03-11T14:42:45Z in response to JohnT.ReynoldsI 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.
Re: The value of Coaches over Enternal UIs - "place holder coaches"2011-03-11T15:03:34Z in response to PrakashKanchanSo 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 270003CQSB54 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2011-03-11T16:21:45Z in response to PrakashKanchanCoaches 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 ;)
Re: The value of Coaches over Enternal UIs2011-03-11T16:34:45Z in response to eddiejmEddie 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...
eddiejm 270003CQSB54 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2011-03-11T16:56:47Z in response to JohnT.Reynoldsand 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.
Re: The value of Coaches over Enternal UIs2011-03-11T17:03:33Z in response to eddiejmEddie,
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.
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
And best of all... Eddie can teach you how to do all of this ;-)
Re: The value of Coaches over Enternal UIs2011-03-11T17:35:39Z in response to JohnT.ReynoldsJohn, 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? :)
Re: The value of Coaches over Enternal UIs2011-03-11T18:01:05Z in response to JohnT.ReynoldsI 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.
Re: The value of Coaches over Enternal UIs2011-03-11T18:05:11Z in response to JeoffWilksThanks 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?
Re: The value of Coaches over Enternal UIs2011-03-11T18:33:03Z in response to JohnT.ReynoldsYes, 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":
ddbailie 2700031HBX25 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2011-03-11T17:25:39Z in response to JohnT.ReynoldsEddie, 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 :)
Re: The value of Coaches over Enternal UIs2011-03-11T17:38:51Z in response to ddbailieVince 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 0600012MYQ23 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2012-02-23T10:59:06Z in response to JohnT.ReynoldsHi,
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 10000004463314 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2012-02-23T16:22:43Z in response to sactelHi 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.
sactel 0600012MYQ23 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2012-02-24T03:14:22Z in response to kolbanThanks 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 110000D4XK7615 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2012-02-23T16:34:37Z in response to sactelYou 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 270002YA3065 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2012-02-23T16:46:31Z in response to JohnT.ReynoldsIf 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.
Zerav 270004G1G84 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2014-06-04T16:49:07Z in response to JohnT.Reynolds
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 2700040K2Q711 PostsACCEPTED ANSWER
Re: The value of Coaches over Enternal UIs2014-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.