Surely there are better things to be spending developer time onâŚ
Like a boring version where time and effort is spent on cleaning dotting the iâs and crossing the Tâs
Implementing some of the outstanding items, like the Dev ops ideaâŚ
6 Likes
As long as they reinstate the prevent endless loop option.
2 Likes
I am that one person that I think falls squarely in the middle.
I did not go to school for programming; I have never and will never build a Raspberry Pi machine.
But I am a geek.
I use use WordPress for web design and MS Power Apps for applications. I set up a bell schedule using Alexa and some Echo Dots.
I think I do pretty well with widgets. I get a lot out of them. I know how to read a trace and I can programmatically interact with the business objects in Kinetic as well as⌠needed. And I still donât know or care what an adapter is.
So, none of this is a surprise, but I will always champion the widgets.
HOWEVER - there is a lot I agree with in @josecgomez 's comment. The leap from âWhat is Epicor?â to âI made a complex working BPM or Functionâ is HUGE. And I donât know that SNAP logic will make that any better.
I still voted for it.
7 Likes
Make it difficult for core logic changes or anything requiring data validation. Make it easy for cosmetic changes like forms edits or report tweaks. A lot of power in unqualified hands can wreak havoc on system integrity.
1 Like
Yea I def see this being somewhat more useful in app studio, not bpm/function designers
SoâŚwe will be programming with Scratch?
4 Likes
Iâd hate to see how @josecgomez glares at people who vote third party 
6 Likes
3 Likes
This was me after @klincecum tried to convince me to learn and practice code:
Yeah⌠Iâm still a widget guy. Maybe someday.
10 Likes
Hey everyone needs to start somewhere! Maybe Kevin or someone can host a bootcamp for some of us to âlearn the waysâ
2 Likes
Iâm so busy right now, Iâm forgetting âthe waysâ.
8 Likes
Iâve got nothing but respect for you⌠but Iâm not sure this is a winner.
This feels like a classic example of âERP implements something 10 years after everyone else let it dieâ.
I trust/assume that all the C# functionality will still be present. Iâm not coming at it from a âOH NO! MY CHEESE!!!â angle. These visual/WYSIWYG tools just donât work. Weâve all tried a million of them over a million years. There just isnât any way to dress up a tool someone doesnât understand that will make it usable. You canât address a knowledge gap with theming.
(And with AI seemingly being on the cusp of addressing these gaps, the timing here seems less than ideal.)
You just end up with business logic that is wrapped around some proprietary tool and the pleasure of dragging a new dependency around for the next decade. âŚcough, coughâŚService Connect, Jitterbit, Auto Studio, every tool that ever made me deal with XSLTs
Snap is a tool for learning, not doing. Its value is in exposing people to coding paradigms without getting hung up on syntax. It makes doing things more complex in exchange for making teaching things less complex. It a modern iteration of the old Logo turtle.
The current widgets are limiting from a development perspective, sure. But they do have a massive advantage in that they are actually usable by non-technical users. Sure, most of them are only doing the basic things. But they ARE doing them. And not to start a debate, but thereâs almost certainly a limit to the amount of change a non-technical/non-trained user should be able to affect on the system. Iâll skip the threadbare quote, but capability comes with liability.
Unless there is maintenance overhead on the widget system that youâre trying to ameliorate or something like that, this feels like a boondoggle.
13 Likes
OK⌠let me put a different perspective and view on this. but first, a little background:
- i have been writing BPMs (and their predicessors called âBAMSâ for nearly 20 years.
- I am also one that has fought very hard to make these accepted business practice
- I was one who also fought for the addition of Epicor Functions. Before we had those, I also created a âworkaroundâ were I created my own functions within the âTIPâ data structure, and could pass json to various TIP object to execute a âfunctionâ that I had programmed in TIP. Development saw what I did and exclaimed âyou just created your own functionsâ.
- I feel that BPMs (and now FUNCTIONS) are some of the best features we have in Kinetic for our customer-developers to make the system work the way that they want.
BUT ALSO⌠several years ago, Epicor acquired KBMax, and it had a programming interface called SNAP that they had built. Their SNAP implementation allows for hyper complex things to be done. They created their own SNAP Widgets. When I first saw it, I suggested that Kinetic could adopt the SNAP widgets instead of our random boxes. my suggestion was to simply enhance our UI for the BPM Editor⌠not change what we could do within each widget.
If you look at some of the more complex (non-c# widget only BPMs) the screen is very ugly, and very complex to follow⌠lots of crossing lines, lots of boxes, and no documentation.
THEN you get to the BPMs that require a C# block because it is simply too complex to do with Widgets Only. Sometimes those BPMs have a âStartâ box, and a C# box, and that is all. (Maybe a message display box, etc). I am NOT suggesting that we would convert all your C# code into SNAP Widgets! Instead, there would need to be a SNAP WIDGET that allowed for C# inside of it.
MY THOUGHT is NOT to disable anything in how BPMs run⌠Each widget would still work the way that they do, but simply change the UI so that it is not a bunch of boxes with lines, but instead uses the SNAP widget interface.
Someone suggested that SNAP was a learning tool and not a real programming tool⌠i would say that this is false. We have it built into CPQ and it is a real robust tool.
Some have said âWhy spend the time to do this when Kinetic has other things to doâ⌠well⌠one reason is that we already have the SNAP product in CPQ. We use it for several products now⌠I will counter the question with âWhy have two or more different programing interfaces when you can have one common one?â
The point here is that by moving the INTERFACE to SNAP, it would make our development overhead at Epicor smaller⌠only one tool instead of two. It is easy to use as it was designed to be easy for Kids and adults alike, and yet, we can build our own SNAP Widgets to mirror all the capabilities of the BPM widgets, giving us a better UI to work in.
10 Likes
What else uses it besides CPQ?
If it reduces tech debt to only have one click to code flavor in Epicor and you guys calculated the ROI is worth it, I donât think there would be a huge revolt. It just sounds like something that will take a lot of effort, and wouldnât directly benefit most of us as much as other open ideas.
If you do go forward with this idea, make sure all widget BPMâs covert to the new flavor flawlessly without user intervention.. we all are already up to our eyeballs in kintetic conversions and would DIE if any more work is dumped on us in the name of progress.
8 Likes
Itâs never that simple though. See: Classic to kinetic
I agree with many comments above. We are in so much pain with so many other changes and unaddressed bugs and problems (regardless of whether Epicor insists on calling them enhancements). This is the absolute last thing we need.
5 Likes
I guess my hesitation here is I am not used to the SNAP style of interface at all. The current widgets are ugly but simple and straight forward. Not saying I hate the idea!
I would completely open to this if we could flip between the two interfaces (widget/SNAP) in the BPM Designer and see how it compares. Now, I understand that would probably be a nightmare to code, but I think it would be beneficial to see how each of the interfaces compare for ourselves.
Hey, I might just like the SNAP interface better than the current method!
I might nitpick slightly regarding learning - in education visual programming is only applied for introduction. Snap and Scratch occasionally turn up at the start of an âIntro to CSâ class, usually in primary education, occasionally in secondary settings such as a community college. Those lessons are normally transferred to actual code long before the end of that class.
It makes sense why this is attractive to Epicor, having recently acquired Snap artifacts associated with KBMax / CPQ. Snap was a liability to KBMax, a friction applied to adoption, in a product marketed at a pricing and implementation scale commonly associated to businesses with access to competent programmers. Hiring or contracting highly skilled work in Snap or Scratch is astonishingly difficult. Itâs not something programmers would admit on a resume.
Most importantly, visual programming is incompatible with useful application of competent version control. Compatibility with third party version control needs to be supported.
2 Likes
I use widgets about as much as I do code so Iâm not against this idea however, like others, it seems like a big change without as much upside for us users as we transition from Classic to Kinetic. There are many ideas logged about gaps in Kinetic --and Kinetic tools- that should be considered with a higher QOL improvement.
7 Likes
For the sake of argument, letâs say formulas in Excel are a form of writing code.
Who is more of a superuser:
- The user who does literally thousands of COUNTIFS() and SUMPRODUCT() formulas to make a table of data?
- Or the user who does the same task in seconds with a PivotTable?
Yes, you have a lot of knowledge if you know how to use all of these formulas. But the PivotTable is faster and likely more accurate, and much easier to change dynamically.
I just donât buy it that coders are better or smarter people or that pure coding is better than tools that do the work. I think this thinking needs to change.
âOkay, so youâre a rocket scientist.â
5 Likes