We need to purchase a new App server. Does anyone know if there would be changes in the server sizing specs for E11 vs current 10.2.700 specs.
TIA
We always spec above what Epicor recommends. I wouldn’t think that E11 would be too much different than 10.2.700. So if you at a minimum purchased app server to meet the 10.2.700 requirements you should be able to run E11. I’d go above the minimum of what Epicor recommends. In case there is a slight change with E11.
2 Likes
The only thing I can think of is better Network Cards and perhaps a more dedicated NIC Channel.
The way I understand it that there will be alot more REST API Calls, even to render your UI.
Smart Client:
Haso Gets Grocery List → Goes to Supermarket → Comes Back with Items
Kinetic:
Haso Go Buy Milk → Goes to Supermarket → Comes Back, Haso Buy Beans → Goes to Supermarket → Comes Back, Haso Buy Rope → Goes to Supermarket → Comes Back.
While your Local PC requirements may go down from 8gb to 4gb (since the Client ultimately just renders) your Server requirements may go from 64GB Ram to 120GB Ram, since the Server does most of the work and the Client merely displays it.
Just throwing out random numbers, 120GB may be overkill even for a web server, not sure how the caching works for the layouts either.
3 Likes
I’m not sure that’s a totally fair explanation. There’s a lot of costs in the marshalling and unmarshalling of data in WCF that you won’t have in Kinetic. If the REST calls are to EFx, you have the ability to reduce the amount of data on each trip and shape it in a way that easier for the UI to digest than we can with WCF.
I would think you’re going to want a little more server if you’re doing more in Directives than in the Client. But that’s just a guess from a cloud guy. 
2 Likes
I think we better have an intervention here. Someone take that rope away from Haso. It’s going to be alright Haso…Kinetic won’t be THAT bad. I don’t think so anyway.
Ok…
The new UX works a little differently to Haso’s shopping analogy but I will try and explain the difference.
The smart client today once downloaded after an update has all of the UI logic locally. You open a Form and it has to load that dll into memory (all tabs/inputs) then you can enter say an order number and it will make a network call to the server that will query the database do some processing and return to the client. Things like Row rules (if this then that) type conditions apply on the client and some other field changes may call validation to the server as you change them.
The browser works as follows. You open the home shell and it downloads and caches the angular app. The app is much smaller than the smart client and next time opening its already cached. So opening in the browser takes a 1-2 seconds.
When you open an “App” (we do not call them forms anymore). The shell will make a request for say Erp.UI.OrderEntry this request returns the definition of the app which then gets cached and rendered. Our Apps are metadata defined - all translation and customization layers and personalization happens on the server so we end up with much faster rendering times. Also the app only renders what you are looking at so not all the tabs, inputs need to be painted. (Again another optimization common in a browser)
Then we call GetList on the API to show a list of orders and you can click into one (which calls GetByID) and then other changes that trigger logic occur.
All the Row Rules (if this then that) is evaluated on the client side so the number of calls to the server is actually the same.
Except we now have ETag’s on GET requests. That means say we ask for a list of values in a drop down or the definition of an app, if we already made that request before the server does not need to send us the response cutting down the network traffic.
Hence there is no additional overhead for RAM on the server. However having a separate NIC for App Server to SQL traffic vs Client to App Server traffic is good guidance depending on your size.
I hope that helps.
9 Likes