So there is logic that runs on the client side but it is declarative. All of the Epicor ERP kinetic applications leverage this framework and as partners and customers you have the same power to taylor that as necessary, new pages, components, validations, navigation, chaining of events, rules etc. You can do many of the things that needed code before.
As an example, add a grid to a tracker from a BAQ subscribing to the record in context, or automating some chain of events like an RMA disposition and printing labels can all be done without code via App Studio and BAQ’s / Epicor functions. Also now you can layer logic so as a partner you can easily package solutions more easily.
We absolutely put ourselves in our customer’s and partners shoes balancing the need to invest in technology and ensure we do not leave people behind. That is why classic customizations and all investments in them will continue to just work with no drama in the smart client.
We have a duty to all of our customers to stay relevant investing in the agility that comes with being browser and cloud first. Open API’s and web based standards are expected. As an example web components lights up the ability to use C# via WASM in the browser, allowing the same language people already know for on the server and client. Also they support UI components providing even more use cases. We do not have web component support baked into 10.2.600 at the moment but it is on our roadmap and we have already verified the process.
It is a big change but it is a familiar and necessary change. We are listening and acting on feedback and appreciate everyone who is putting themselves forward to learn and work with us.
Aaron - my previous reply should answer some of your questions but we will be sharing some more technical details as to how this now works for alignment. Insights was going to provide this context but I will work with our teams to see if we can run some interactive sessions and get them posted for those that would be interested.
Thank you for this reply, it goes a long way reassuring me about the whole deal. I think the scary part is the 2 years support limit for Epicor releases. If I start migrating customizations when the last Epicor build that still supports classic screens ships, 2 years isn’t a whole lot of time to migrate some of our customers with heavier customizations. And starting to migrate before this, with no actual framework documentation and everything in flux, and probably lots of bugs to correct (as is usual and normal for large increments in technology), isn’t such a happy thought either. It would help if Epicor would commit to support the last “classic” build they will ship for a longer period than the usual two years. Maybe also make your roadmap known at large, so we can see what is planned, even if there is no date attached. It makes it easier to strategize and plan our response.
You can do many of the things that needed code before.
But I can’t realistically begin migrating a customer until I can for sure do ALL of the things that needed code before, and I just don’t see how you can anticipate the needs of all customers either.
I guess it would help a lot to have some Kinetic framework developer-aimed documentation available too, right now the only thing we can see is what has been shipped, and trying to translate that to what we are currently developing and maintaining for our customers has been a challenge to say the least.
Re the smart client, our product management team will be sharing some more details in time but we do not expect it to disappear, we just expect over time it is not going to be needed.
This technology transformation is not the same as when we went from 9.X to 10 at the time changes to the server side stack and databases felt scary and different but it was the right thing to do. We can and have adopted a hybrid based approach for the client its progressive and intentional we want people to easily upgrade and adopt kinetic when ready. Change is difficult though so we have to drive the change for the better but not at the cost of disruption.
I will organise sessions with our teams on the framework and work to ensure we get good exposure across this forum and our EUG groups. We do have advisory groups with customers and partners for our planning into more detailed (under NDA based work) for those that are not aware of that we can look to include.
Thanks, I look forward to see what you guys come up with. I like what I see in regards to the new UI, but I also am apprehensive about the nightmares I will have about it in the future…
@bmanners To directly answer your question, there is a code editor that now ships with Epicor. You can find it in the inetpub\wwwroot{AppServerName}\Server\Apps\MetaFX\assets\monaco\vs
You can also find it in inetpub\wwwroot{AppServerName}Server\Apps\ERP\Home\assets\monaco\vs
So Epicor is now shipping MS VS Code with their product but you just can’t use it to edit code…yet.
Oh man…when I click on edit on a Kinetic screen one day and VS code opens up there will a BIG HAPPY DANCE happening in my office!!! closely followed by strange looks from my co workers
I think you all have made some good points here. I will have to dig into what has shipped in 10.2.600.3 and see what can be achieved with the current state of customisation tools. Maybe I have been putting too much business logic into the UI and this is the kick in the pants I needed to rethink my approach. Although we are on 10.2.400 so no access to fucntions yet which will open up some options. We have plans in place to update to 10.2.600 in the next month or 2.
I do find the screens that have been heavily customised are the ones that are important to our business, they are the screens that justify the investment. These are also the ones that use code for the customisations. I guess my (our?) challenge is to look at those customisations and think about how I (we) might achieve the same result without all the code in the UI (maybe some code in functions or BPM’s instead).
