Yeah that’s exactly what happened earlier. We were 3 on the call and all loading the ‘Order Entry’ program at the same time. I’ll try to reproduce it using different browsers / smart client but that’s weird what happens in MetaUI(Program)\cache each time a user open it
Also, I’ll have to investigate more about this but once someone created a kinetic personnalization on the menu, it seemed like it blocks users to access the menu for a certain time we had errors when opening it. But it could be linked to simply opening the menu all at the same time !
Dude it totally does block them. I had to delete the file out of the websites cache folder (that we have been referencing) to get it working in my demo environment. It’s like sometimes it’s super hosed! Like can’t even open the form. We have had that too. In fact, two - three days after go live!
Yeah I have no clue what purpose this serves. I mean there’s still a client cache so I am not sure what’s going on with this or what kind of purpose it achieves.
May I ask what is the value of your KineticUseFileSystemNotDB parameter? Ours is set to false. It should mostly use the database (Ice.XXXDef) to load Kinetic forms and not the MetaUI folder.
SELECT Key1, SysCharacter01 FROM Ice.SysConfig WHERE Key1 = 'KineticUseFileSystemNotDB'
For the cache, I don’t understand why it is both stored in the database and into MetaUI files. The conversion workbench task 191 migrates MetaUI JSON files into the database (Ice.XXXDef). Once it is done and KineticUseFileSystemNotDB is set to false, I don’t think these files are being used anymore.
I just tried to load 3 project entries at the same time and could not replicate the issue. Only one JSON file gets generated per language in the cache folder.
I will try your steps tomorrow, but your parameter being true is a huge difference.
Epicor should really give more details about this parameter. Open up Conversion Workbench. Search for task 192 “SetKineticUseFileSystemNotDBFlag”.
This task sets the parameter KineticUseFileSystemNotDB flag to false.
false = use DB (Ice.XXXDef)
true = use filesystem (Meta UI folder)
A year ago, we went “all in” Kinetic web. We had unexpected issues with Kinetic dashboards and layers. I had to decompile Epicor code to understand that the parameter KineticUseFileSystemNotDB had a huge impact on how they handle Kinetic forms. Ours was set to true.
We ran the conversion task 191 to migrate MetaUI JSON files to DB, and then, task 192 to set the KineticUseFileSystemNotDB to false (permanently).
No issues since, except for the cache being the only thing that Epicor seems to manage both via the MetaUI folder and the database.
EDIT: I think you will get much less files written to this MetaUI folder (only the cache). It may as well improve the performance. I suggest getting the opinion of others before doing that move.
Vincent, you’re another testament to why I love this forum. Thank you so much for sharing that knowledge with us. I hope it was equally as satisfying to share all that work you did with someone as it was for me to read it- all that time spent decompiling and understanding.
Not sure about the 3 sessions since I just used 2 different users in 2 different web browsers (Chrome and Firefox) and both of them had the same language AND personnalization (Which is none):
Open any menu (In my example, Misc Charge / Credit)
ctrl + alt + i on only one of the user will clear the cache file on the server for its corresponding language of the menu
Open the menu by the 2 users at the same time (1-2 seconds apart). The 1st user will see the program but the 2nd user wil get an ‘Business Layer Exception undefined’ error.
The crazy thing is that if the 1st user, who was able to access the menu refresh his screen or go back to his home page and reopen the same menu try to access it, it won’t work. In fact, I think it won’t work for anyone who has the same language that the locked cache file
If the 2 users have different languages, here is how it works (Assuming that you did ctrl + alt + i to clear cache of this specific menu)
The 1st user who loads the menu will create an response.(language).(Menu) file in the cache folder
The 2nd user who loads the menu will replace the existing cache file with a new response.(language).(Menu) file in the cache folder
Both of those users are able to access the menu because there wasn’t any conflict with the files since it’s not generating the same one
So, in the end, only 1 cache seems to be stored in the MetaUI/Cache folder per menu
If the 2 users have different personnalizations, there will only be 1 cache file and admitting that the last user that opened the menu is the one with the personnalization, it will have a GUID at the end of the file. So , again, since it’s not the same ID, it will work for both of them even if they open it at the same time
***Also, my KineticUseFileSystemNotDB is set to True
Even though setting the format culture/language fixed this issue for us now, I have no faith that it will remain fixed. I think the issue runs a lot deeper. With that said, I rejected the Solution offered and asked for an analysis of why this keeps happening (we’ve been dealing with it for almost 3 years) and what steps are being taken to remediate the issue. I posted a video demonstrating how the bug can be triggered on demand using @utaylor 's method and reproduction steps.
My case # is CS0003951400 if you want to reference it in yours. If anyone else has a case open about this, please post it here. We should all cross-reference these cases for support so they know it’s not an isolated issue.
I just did the first steps you described multiple times. 2 different users in 2 different browsers. I was not able to reproduce the issue.
What is your Epicor version? Mine is 2023.1.12
What does your generated cache file looks like?
I have opened up a case regarding the KineticUseFileSystemNotDB. I asked Epicor to provide info and recommendation about this parameter. I feel like every Kinetic customers having release >= 2021.1.7 should have this parameter set to FALSE.
In fact, the conversion workbench task that sets this parameter to FALSE was introduced in the 2021.1.7 release (see release notes).
Vincent, I am going to set it to false in my demo environment and report back tomorrow when I test it.
I am with you, why is this even a setting if it needs to be false. They told me that in my case too,
“it should be false.” Okay, maybe I missed that in the post conversion steps or something, but is it just a coincidence that three of us here had it set to true? Maybe we all three missed that step in the post conversion rules or the migration guides.
The whole thing is being handled differently than I see most problems. Every other issue I put in after go live resorted in a fix and it didn’t come back again, a workaround that worked every time (in our case it’s a list of 10 things to do, 191, 181, ctr + alt + i, english language/or any language on every user, parmeter = false), or a PRB accepted so that Epicor takes action and prevents this from ever happening. @spaceage has said they’ve dealt with it for three years. And it’s all of us on this thread dealing with it still.
I don’t know what has made this to be something that’s not getting resolved, maybe we are the exception.
You should look up the last execution date. In my case, the task had been executed, but … someone had us execute a mysterious dark SQL script each time we upgraded our database. The script literally updated this parameter to true, to fix an issue with the Configurator module (a module we don’t even have). There is a thread about it on this forum.
Thank you, I threw a post on my case asking for them to give a name to this problem. Establish it as a PRB, or multiple PRBs if that’s the case. At least name this issue and then do something about it. Like fix it so that we don’t have to do this dance. Make the language field mandatory, set that parameter to false then and don’t have other random scripts change it back. tell us the proper procedure to publish a layer or manage personalizations like whether we have to do a write to disk conversion after every publish or every personlization, etc.
