ECL Success/Failure Stories

Aaron Van

Greetings,

 

So our company is about to make a decision on whether or not to take the client (forms) outside of the Metastorm IDE to enhance our capabilities in designing an industry standard web application using C# + HTML5 + etc... in VS2012. If anyone has any experience taking on projects where you used the Metastorm IDE for the workflow and role management, but created your front-end externally utilizing the ECL we would love to hear about it. 

 

The more detail the better, so please indulge if you are particularly proud about how you and your team developed patterns to utilize the ECL the most effectively while creating a robust interface for the users. We would also like to know if you had no luck with an external approach and the project bombed out or something of that nature.

 

We have mocked up an MVC project that we believe will work, but obviously would like to hear from other developers for their opinion.

 

Thanks :smileyhappy:

 

...aaron

Robert Vignerot

I have been using MBPM for 13 years and have never done a 100% rip and replace on the UI.  Personally, I'm very much against it because I think you lose one of the biggest benefits of MBPM which is the rapid iteration/deployment capabilities.  I fully understand the limitations of the MBPM UI, but unless this is for an external audience on a public site, I would recommend against it.

 

Please understand, I am NOT saying that it won't work.  I'm only saying that it will take much longer and will be much harder to maintain in the long run.

Tony Wheeler

Last year, I built a WinForms UI against the 9.0 ECL.WS just to learn the ins and outs and while there is no reason why you can't do this, there are some issues you may run into depending on how you design your processes/forms. They might not even be problems if you are truly doing a clean separation of concerns, simply using the ECL.WS as the data access for your viewmodel.

 

1) There are certain presentation layer properties on FormFields that aren't available through the ECL.WS (like z-index)

2) Stand-alone labels (not captions) are not available through the ECL.WS

3) Anything normally invoked from the client side with custom javascript or the BPM ajax library from a BPM form (chained actions, auto-refill of dependencies) won't work. Calling a server-side Refill() from ECL.WS WILL work, provided those field-level dependencies are defined on the form.

 

I would have to agree with Rob, that you lose many of the benefits of BPM by doing this. If the issue is simply a matter of extending capabilities of the BPM form, you can use calculated labels fields to print literal HTML to the form and attach javascript handlers to that HTML for your handled events and/or to bind that HTML "control" to a BPM FormField either off to the side or invisible. This approach gives you the best of both worlds in that you can use any javascript/HTML within the out-of-the-box web client.

Aaron Van

Thanks for the responses, I really appreciate the input especially from the two of you who always have insightful posts.

 

"...you lose one of the biggest benefits of MBPM which is the rapid iteration/deployment capabilities."

 

I see the biggest benefits of the BPM solution in the workflow and the handling of tasks assigned to specific roles.

 

"I fully understand the limitations of the MBPM UI, but unless this is for an external audience on a public site, I would recommend against it."

 

Just because it will be an internal application doesn't mean we should sacrifice usability and industry standard practices when it comes to the client side. We are just finding that we have been making compromises with the business when we cannot accomodate requests because of UI restrictions.

 

 I'm only saying that it will take much longer and will be much harder to maintain in the long run.

 

Maintanability is one of the main reasons we are considering shifting away from the client and building our own. There is no real way to use any programming patterns when locked in the paradigm that the IDE provides. We have attempted as much as possible to extract all logic out of the event handlers of Metastorm and move it to Server Side Scripts since you cannot debug in Visual Studio anything but server side script code. It seems as though we have abstracted as much as possible to make our logic generic, reusable, understandle, and maintainable. Maybe it's just a reflection of our immaturity with the Metastorm application or our maturity of .NET solution that is making us blind to the capabilities of the IDE.

 

"They might not even be problems if you are truly doing a clean separation of concerns, simply using the ECL.WS as the data access for your viewmodel."

The plan is in fact to separate the layers in such a way that Metastorm provides the workflow map and the role management , but our application handles the rest. We are not writing our business data to Metastorm DB nor are we utilizing any form design in the IDE. We have already mocked up a fairly rudimentary application as a poc which seems to have promise.

 

I'd rather not get into the details of our project, but hear from more people on their personal experience with taking this route. 

 

Thanks Again...

 

 

McGaw_Phil

Hi Aaron,

 

Coming from an impartial perspective, it sounds to me like you might be best using Windows Workflow Foundation as your workflow engine rather than Metastorm, especially since you're not planning on using the Metastorm database as the main database for your information.  Have you already dismissed this idea?

 

I've had success in previous versions of Metastorm creating external user interfaces and communicating to the engine via the TP, but haven't worked on any v9 projects where the entire Metastorm User Interface was to be replaced.

 

I'm guessing you would just be firing actions/flags via ECL, and your entire presentation layer would just be using your own data layer (nHibernate, LINQ or straight Sql) so I can't see you having any problems with this implementation, but to go back to my first comment, if you go down this route, I think you may as well go the whole hog and go down the WWF route.

 

Hope I don't get my wrist smacked for the above comment.

 

All the best

Phil

Tony Wheeler

I can't claim to be 100% impartial, but I think you'll find that WWF lacks many of the high level "developer-friendly" abstractions MBPM provides out-of-the-box. For example, IIRC, the concept of a "User Stage" does not even exist... you have to do a lot of work/code just to define a single "State" as part of a larger steady-state machine. The same could be said about the concept of a "Folder" that represents a unit of work moving around in your workflow. You'd be in charge of modelling it all. It gets very academic very quickly, whereas MBPM provides you a PRACTICAL object model out-of-the-box.

 

Add to that, a Designer that non-developers can actually understand, user/role management, access control based on dynamic roles (auto-calculation of ToDo/Watch lists), an easy API for one-off triggering of Actions/Flags, auto-routing based on the VISUAL process map... the list goes on.

 

Certainly, WWF is powerful framework that you could THEORETICALLY use to build a 100% customized workflow solution, but the same could be said about pure assembly and chip instructions... I wouldn’t want to do this though

Aaron Van

Hey Phil,

Thanks for the honest response.

We have considered WF, but the learning curve for our other developers is much higher compared to Metastorm's friendly UI based layout. We are essentially pot committed to Metastorm's workflow since we've designed a major portion of our business process utilizing it. It would be wasted effort if we had to redesign it in WF and additional time is not something we can afford.

We decided early on (before we started this project) that we were not using the flat Meta database for our business data. We would have decided early on in this project to use external forms as well but we were misinformed of the capabilities of the ECL. So now we are just gathering war stories from around the community for some metrics to base our decision on.

 

Thanks again,

 

...aaron

Michael_Turek

"Just because it will be an internal application doesn't mean we should sacrifice usability and industry standard practices when it comes to the client side. We are just finding that we have been making compromises with the business when we cannot accomodate requests because of UI restrictions."

 

 

We currently are using the ECL in 7.6 and are in process of migrating to 9.2.  I was hoping the look and flexibility of creating the UI was substantially upgraded enough in the 9.x version - so that I could move our custom UI piece back to Metastorm.  The reason why I want to do this, is because it almost enforces a consistent pattern which should result in more standardization and less maintenance. 

 

But, currently having to (and like you said) "compromise" and force a redesign, negates this wishful thinking.  For example - setting a control's behavior based on an expression - can't do it.  Now that I can't set something to readonly or optional based on some logic - this forces a redesign in many ways.  I don't want to comprimise by adding 3 controls to the form only to have the desired property set on each control - then hide those not used. 

 

I feel the same exact way Aaron, the UI is the first thing the business sees (exec to front line).  If another product "looks" better, they will natually look in that direction.  And in my opinion this product would run away from a lot of competition if the UI experience was given a higher priority.

Aaron Van

I will say that we have made some great strides in coming up with a functional framework to use MVC4 and the ECL WS together in simple harmony. It has been 1 month since we've started down this path and are already well ahead of where we would have been had we stuck it out with the UI designer. I think the designer has it's place for a large majority of LOB applications and I've certainly heard a number of success stories both here and through contractors. It just was not equipped for our enterprise level application which required a large portion of business logic which most often trickled down to the client side UI. The freedom to use pattern programming such as mvvm for client side data binding is an uplifting feeling after 3-6 months trying to hack such functionality into Metastorm forms. 

 

The ECL engine is used to maintain workflow states as well as some workflow related variables that we do not want to pollute our core business database with. It also tracks the roles that are assigned to specific stages which are dynamic and pulled from AD queries (although this is not implemented yet). And it does both of things quite efficiently without many hickups aside from the ocassional 1-2 second lag when hitting a stage with conditional actions.

 

I think the thing that surprises me the most is there is barely any mention of developing the UI outside of Metastorm and using the engine to control the workflow (a la Windows Workflow). I think once a pattern is researched and settled upon to connect the two sides it becomes quite an efficient process.

Dongmei He

Hi Aaron,

Our company is facing the same problems as your company. How is the project coming along? Did it work for your company?

Please share your experiences with me and thank you very much.

 

 

Aaron Van

Hey Marie,

 

We are in the final stages of getting the product ready for simulation testing. There have been some snags and catches here and there while implementing Metastorm as the main driving force behind the workflow, but all-in-all it has been a success. I am kind of kicking myself for not writing down the problems we faced and how we remedied them through either code changes or workflow changes. I wanted to (and may still) write a general framework for MVC4 and Metastorm to coexist and the notes as I was going along probably would have helped. I'll most likely rediscover them when doing documentation.

 

The architecture is implemented pretty much how I described in March above. 

 

• We wrapped the ECL .net object in a WCF service.
• We utilize the service to fetch Todo list, Watch list, and Blank forms. We didn't find a need to use the Admin forms list since those are detached from the workflow and can be written through straight HTML and other service methods.
• In MVC controller actions we retrieved the action buttons for the current stage and added them to a List which was used to render them on the navigation bar of the page.
• The POST mvc actions sets the model writing to the DB and moved the workflow using the action name rendered in the navigation buttons.
• We were able to utilize all the HTML5 features we desired and build up an application that uses an mvvm pattern with change detection using Knockout, validation using jQuery, and a number of other advanced elements not possible through the standard Metastorm UI.
• Roles are dynamic which are provided through a web service call with an enum as a parameter describing what users to return to Metastorm.

As we role the product out I'd say we will begin focusing on the optimization of when to use the workflow and when to not, but that hinges a bit on your operations process more so than the application itself.

 

Let me know if you have any direct questions.

 

...aaron

Dongmei He

Thanks Aaron. That's a good news for us.

 

I have several questions:

 

1) Is your product for internal or external use? What number of users are you expecting to use it simultaneously?

2) Do you have heavy forms with considerable controls? If so, how is the performance?

3) Do you have a way to work around chain actions?

4) Are sub process and raising flag available through the ECL API or anything in MBPM system is not provided in the ECL API?

5) Which ORM do you use for accessing your main database (not mbpm process database) and how is the performance?

 

Marie

Aaron Van

1. It is an internal application used by operations but integrated with external client facing applications that also takes action on the workflow by raising flags through webservice calls. We don't expost the ECL API directly over web service, rather wrap it with our own WCF interface with proper security for both internal and external use. We are expecting around 100+ users for initial ramp up.

 

2. Some forms are light some are heavy. The views are MVC razor views and we use Kendo controls for a few pages. So the performance is on par with any other web application written using razor. Metastorm only provides the action buttons and some process specific variables if we need to hide or show sections based on some pathway the user takes.

 

3. We don't necessarily use Metastorm in the same manner that the Designer and default web front end does. Where the default opens an action and shows the view with an [ok] [cancel], ours opens views based on the stage and the actions are started and completed when a user clicks one of the dynamic navigation buttons fed by the ECL. 

The main thing to note is the difference between Metastorm's default of (Start Action, Display/Edit View, End Action) vs (Start Action/End Action and display view on stages). 

 

4. Nearly everything that Metastorm does internally is exposed through the API.

5. We use EF5 to communicate with our DB server and have had good success with the caveat that you must watch the generated TSQL since it can get sloppy if you don't do any optimization.

 

There was a lot of blood, sweat, and tears to think through how it should all dance together but I think we've made it through.

Dongmei He

Sorry that I couldn't sign in for several days. Thanks a lot for sharing your insights and it will keep us moving to this direction more comfortably.

 

Thanks again.

Marie

Apperson_Rory

Aaron, sorry for the late reply. It looks like you've already gotten a lot of useful feedback, but I'd like to say that we are also successfully using the ECL. I'm surprised at how well it works, actually. We have multiple BPM processes running in production where we have completely replaced the front-end with a Win32 UI. In addition to that, I recently had the need to raise a flag using the ECL, and I found that to be completely straightforward as well.

One problem I have found with the ECL is that when you submit an action, there is some sort of delay before the to-do list is updated to reflect the absence or presence (in the case of a new folder action) of the folder. Ideally, the submit action would be a synchronous operation which wouldn't return until the to-do list was refreshed on the server, but it doesn't appear to be that way. The only way I have been able to "reasonably" overcome this is to introduce some sort of minor delay into my code before re-querying the to-do list. This is obviously way less than optimal, but I cannot think of any other way around it.

Anyway, I hope this helps, and good luck!

-Rory