Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..
657 views

As a developer, what's your take on the Process Designer?

So, HP has rolled on 9.41.  With 9.3, they dipped their toe in the water with Process Designer; with 9.4, they pushed harder in that direction.  With 9.41, our software reps have told us that anyone standing up a new implementation of HPSM will be forced to use Process Designer via the 'Codeless' deployment of HPSM.

 

I confess, my only familiarity with it has been in demos and kicking the tires in some OOB systems.  But I gotta say, I do _NOT_ like Process Designer.

 

I understand that the goal is to make upgrades simpler by separating what HP will touch in their upgrades from what normal users will touch in configuring and customizing a system.  I also understand the sales pitch that 'anyone will be able to use PD' without knowing how to actually code in HPSM.  

 

But, to me, it looks like they took something simple and straightforward and broke it, in an attempt to make it appear better than it actually is.

 

So, I'm looking for opinions from others on this forum.  Have you used the new 'Codeless' HPSM?  Do you like PD, or is it as clunky and awkward as it looks?  Has it made things simpler and more powerful, expanding the flexibility of HPSM to the average process owner within an organization, or is the same set of developers who had the power to do things before needing to re-learn everything to do it in a more complicated way?  Are you using PD?  If you had the choice, would you stick with PD?  

0 Likes
10 Replies
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: As a developer, what's your take on the Process Designer?

Starting with PD Content Pack 4, I've recommended that every customer go full-on PD and use as little legacy tailoring as possible (using legacy methods only if something is not possible to do with PD methods).

--I believe the base builds are better than anything on SC/SM previously. We are doing fewer modifications in order to deploy and leveraging the out of box builds more completely than previously.

--PD development has been, in my experience, fast. There are still some holes, but the core PD frameworks are being updated and expanded rapidly.

--It is far, far easier for someone who does not have weeks to attend training and months to develop proficiency in SM legacy toolsets to develop proficiency with process designer and be able to make modifications. I have a customer who modified their change notifications, for example, with no training.

--As someone with extensive experience delivering SM training, I think this may be the only time I've seen the classic tailoring toolset described as "simple and straightforward".

 

Note that 9.40 introduced all new builds running in Codeless. 9.41's big change is the introduction of Hybrid mode, which makes it possible to migrate to PD in stages. 

--Note that ALL PD builds, from PD1 through 9.41, call legacy tailoring components at record add/save. For example, if your PD workflow uses a form, and that form has an associated format control record, that FC will be called.

--A major part of 9.41, which was missing previously, are tools to allow an upgrading customer to better levarage/reuse existing tailoring rather than having to convert to PD in one big bang. For exmaple, hybrid provides the option to map the legacy SD/IM modules to simple workflows that leverage your legacy format control and other classic tailoring objects. For example, in Hybrid Mode, IM uses your existing forms for each IM category (e.g. the logging phase uses "IM.open.incident", Investigation uses "IM.update.incident", closure "IM.close.incident". It essentially takes the classic IM Module and remaps it directly to PD, with the three phases managing the display of the open, update, and closure forms. This allows you to then migrate to new PD workflows over time, category-by-category, rather than using a big bang. 

----------------------------------------------------
Kudos - what, where, how, and why
Want Good Answers? Ask Good Questions...
0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: As a developer, what's your take on the Process Designer?

Thanks for your input, John.  I appreciate someone who is in the field giving their feedback.

 

So creating the rulesets via wizard is simpler than writing a line in the formatctrl?  Or is it just picking up HPSM using PD is faster than picking up HPSM legacy development?  In my head, I'm trying to reconcile the lines of code we've put in to formatctrl records, displayscreens, displayoptions, Process records, scripts and ScriptLibrary and rewriting them one at a time using PD.  It's like the 'Expert Search' versus the 'Advanced Search'... it's easier to write a query like:

 

problem.status isin {"Pending Customer", "Work in Progress"} and open.time>date(tod()) 

 

than it is to manually step through the Advanced Search wizard to select a field, select an operator, select a comparison, lather, rinse and repeat as needed.

 

 

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: As a developer, what's your take on the Process Designer?

I guess it comes down to perspectives.

From a developer view, it's much easier to do a lot with a single line of code, and cool.

From a customer or support personel view, that single line of code could be hard to maintain as they may not have the experience, training or understanding on how that code works.

 

As an example, I used to have customers who used Service Desk 4.x where the business logic was created via fill in the blanks panels. The customer could add in their own business logic with minimal training. It was easy to track down and fix issues as it was all centralised and restricted. The restriction was why they went to servicecenter where there were almost unrestricted customisation. They required more training and consultants on servicecenter. So pro and con for both softwares.

0 Likes
Highlighted
Established Member..
Established Member..

Re: As a developer, what's your take on the Process Designer?

it looks like they took something simple and straightforward and broke it

 

Tell me that wasn't in reference to the legacy/standard HPSM implementation mode?

 

 

 

Highlighted
Established Member..
Established Member..

Re: As a developer, what's your take on the Process Designer?

I do like the layout of the workflows, it's easier to see where updates are being made and to control everything in one nice gui... with a bit of work, i have high hopes for the PD.

 

the one thing that annoyed me was that i couldn't see a way to use field names (instead of display names).

your example query:

 

   problem.status isin {"Pending Customer", "Work in Progress"} and open.time>date(tod())

 

You would select something like "Status" instead of problem.status. Sometimes the display names aren't quite enough to go on quickly and i'd prefer to use the exact names that i find in the database and that external systems are referencing. Something i'm sure will be updated.

 

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: As a developer, what's your take on the Process Designer?

I've to say I definitely like idea PD carries. Of course it's a bit "pig with lipstick"-like - but that's what you get when renovate old instead of building completely new from scratch.

 

In my experience, old gurus may have a steeper learning curve, because like the previous posters told, the old way things were done was effective (like a command-line tool), but oh boy it was an easy way to make upgrades complicated. I understand why HP tries to separate OOB workflows and push users to upgrade systems more often.

 

Hybrid mode is a nice way to start workflow update with a simpler process and continue to more complicated ones (yes, Change Management) when you've learnt how to play with a need kid on the block. Personally, a big bang upgrade was a intimidating thought and a hybrid path surely makes an PD upgrade more lucrative.

 

In Change Management, I like most the "Models" approach. The task customization in a pre-PD world was a pretty painful (or maybe it was just me), but now I finally have a tool that allows a easily configurable way to create and reuse "task templates" for different purposes.

 

PD is still under development - one example, at least in SM 9.40 OOB Change Task numbering was an old T1234, but IM tickets used a much more sophisticated looking IM12345-T123. I wish HP could also show on a PD graphical worklow the emails process is going to send. Only good reason it's missing (I guess) is that the way notifications are constructed will be (finally) redone.

---
Moving on, this account is no longer active. Best regards, Kelalek
- So Long, and Thanks for All the Fish
0 Likes
Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Re: As a developer, what's your take on the Process Designer?


@Jacob Heubner wrote:

It's like the 'Expert Search' versus the 'Advanced Search'... it's easier to write a query like:

 

problem.status isin {"Pending Customer", "Work in Progress"} and open.time>date(tod()) 

 

than it is to manually step through the Advanced Search wizard to select a field, select an operator, select a comparison, lather, rinse and repeat as needed. 


I feel you there. It is like that sometimes, using PD. It seems much simpler and quicker to me to write a formatctrl calc or make a trigger than to go through all the steps to make PD rule sets and so forth. The Condition Editor also (which reminds me of those sorts of "codeless everyman thingie which is really just a UI over the code" such as Cherwell) sometimes feels restrictive - why can't I just type "coordinator in $L.file=$lo.user.name"?

 

That being said, making workflows in PD (most of my thoughts here are centered around ChM) is much, much, much better. Having it all centralized instead of running around to all the cm3* tables is great. The development process of workflow creation is much easier. The thing which I like the most about PD (perhaps a small thing) is the workflow transitions. No more needing to change a bunch of Processes and/or whatever else in order to set up automatic phase transitions - you could have tons of automatic transitions for every business occurrence under the sun, all housed right there in the one workflow. Also, if you want to have several different manual transitions out of a phase, you don't have to mess around with multiple displayoptions (which are an upgrade bane anyway) since the workflow will present the button on demand (uses scmessage, pretty cool).

 

I like the way in which the Change Model setup houses the Change Tasks. I'm still playing with that, but it certainly seems to be a much more central place to manage a lot of the aspects of Tasks.

 

For what it's worth, the actual workflow creation UI itself makes for a very nice visual way to present/demo workflows to business users or to include in documentation, etc. 😉

 

In general, I think that (A) for large configuration efforts where you're plugging extensive business process into the tool, PD is excellent. (B) The finer points of how you go about that configuration may seem sluggish, but I suppose the stock answer of "for many things, you'll only have to make a Rule Set once" could apply. (C) The serious decrease in items which you touch (and therefore impact an upgrade) is top-notch. (D) For many smaller tweaks or custom functionality, you may not even be using PD anyway.

 

Disclaimer: I haven't had a customer go to Prod with PD in anything other than KM, so my experience with it has been in several Dev systems, re-creating legacy workflows in PD, functional mockups and demos, and the like.

 

P.S.: The "ease of use for the layman" aspect of PD is attractive, sure, but I'm always hesitant about business customers who want to jump on the developer/admin bandwagon. Client technical team members, climb on board. 😉

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: As a developer, what's your take on the Process Designer?

Two comments:

1. If you only have worked with condition editor in a 9.3x release. it was completely rewritten in 9.40 and is much, much better. 

2. You have the option to write a RAD expression in condition editor instead of using the wizard.

----------------------------------------------------
Kudos - what, where, how, and why
Want Good Answers? Ask Good Questions...
0 Likes
Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Re: As a developer, what's your take on the Process Designer?

Thanks for the tip, John! Right before posting, I had tried typing a RAD evaluation into a Transition Condition (and in the PD syntax for good measure), and when saving it reset the condition to Always. I'll play with it some more. 🙂

 

Edit: Grammar.

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: As a developer, what's your take on the Process Designer?

Just select the RAD Expression type in the condition editor (you cannot mix RAD Expressions and condition editor code). use $L.file as the file variable.

----------------------------------------------------
Kudos - what, where, how, and why
Want Good Answers? Ask Good Questions...
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.