Need advice - Kinetic UI calls different BO Methods than Classic

Over the years, whenever I’ve had a BPM break in an upgrade, the cause was most often the UI changing which BO Methods it calls or the sequence in which it calls them. I’m mostly talking about the small little “helper” methods like ChangeCustomer or ChangePartNum, etc., not the “big” ones like Update or MasterUpdate. (By the way, I’ve NEVER had a BPM break because I used code instead of a widget… I don’t buy the argument that widgets are inherently more upgrade resistant, but that’s a different topic… :slight_smile: )

Anyway, this has taught me to avoid putting method directives on those helper methods, but that’s not always possible. So, it’s something that we’ve just lived with during upgrades, accepting that a handful of directives are prone to breaking due to client side changes.

But nowadays we have Classic UI, Kinetic UI, and other clients like EKW, and they often call different BO Methods! In my code I am constantly finding myself having to write in client dependent conditions - if classic do this, if ekw do that, etc., or just have separate directives geared for the different clients. It’s super frustrating and adds a whole other layer of complexity on the Classic to Browser transition. There have been several posts about this:

Kinetic UI and Classic UI Using Different Service Method For Same Action? - Kinetic ERP - Epicor User Help Forum

More BPM Method Confusion - Kinetic ERP - Epicor User Help Forum

BPM - Working in Classic not in Kinetic - Kinetic ERP - Epicor User Help Forum

Enter Functions. Let’s say I’m creating a Sales Order in a Function. I do a client trace and mimic the BO Method calls in the Function. But… do I mimic the Classic UI method sequences or the Kinetic UI method sequences? For example, Classic will call OnChangeofSoldToCreditCheck, then ChangeSoldToID, then ChangeCustomer when entering the custID and tabbing off. Whereas Kinetic only calls ChangeOrderHedCustomerCustID.

My gut says use the Kinetic methods in Functions, but my hesitation is that we’re still primarily using Classic Sales Order entry. I guess my concern is that the Kinetic method calls could create a slightly different data structure and perhaps miss something that is needed in Classic UI but not needed in Kinetic UI. That said, I have not heard of any issues where you create a record in Kinetic and then run into issues trying to update it in Classic (or vice versa), so maybe I shouldn’t worry.

Another consideration is that I’m writing this Function in v2022.2. Kinetic UI was not as mature two years ago, so how much should I even trust its sequence of BO method calls in the first place? It’s probably already changed a bunch by v2024.2…

2 Likes

Personally I always trace in classic mode, as this will work in Kinetic also… But I don’t know how this will work when the classic client is no longer available… What we really need is for Epicor to fix the tracelog to work in both classic and kinetic mode…

This is an option, but it is not ideal: Kinetic Trace Helper Utility 1.0 (Kinetic Web) Chrome Extension - Kinetic ERP - Epicor User Help Forum

All I really need out of the trace is the sequence of BO method calls and an idea of what dataset manipulations are done between calls… that’s all easy enough from the network tab of dev tools in the browser.

I take that and then try it out in BL Tester. And then I write the code.

If I’m writing a BPM “optimized” for Classic, I’ll mimic the Classic trace. If I’m writing a BPM “optimized” for Kinetic, I’ll mimic the Kinetic browser trace.

If I’m writing a Function where there is no UI, I can’t decide which trace is better to follow.

It might be possible to make it agnostic, then. The main differences in tracelogs should be due to UI differences after all. There is a chance that only the BO calls that are common for both are critical, and the others are just causing side effects that you don’t need in your case or UI specific functionality and could be omitted.

However, if you find that they are needed, I would follow the kinetic trace log as I would think its more modern and better reflects what Epicor considers best practice.

2 Likes

since we have been enhancing Kinetic (browser-based) for the past few years, we have probably added new features that are exposed in the browser, but not necessarily in the smart client. Remember that the smart client is not being enhanced as we proceed.
That said, I would always use the browser-based version of the software for determining how things should work from now on.

6 Likes

I feel your pain, supporting both is hard, but you do what you gotta do.

I understand with the new UI, sometimes it just makes sense to change the methods around, but I also think a few of their devs have got a little trigger happy with making new methods to make their life easier while not considering it’s a breaking change.

Tim is right though, follow the Kinetic Web UI for the future, and manage the exceptions for classic. We won’t have it much longer.

4 Likes