Leave the service as Ice.BO.UD103svc, but change the Service Method to GetRows and the Table Name to UD103A.
Haven’t had a chance to test it, but I can play with it in the morning if that doesn’t work.
1 Like
Awesome! GetRows made the difference… Thank you!
1 Like
@hmwillett , I think I know the answer, but I also know I could be wrong.
Can this be done in SaaS Cloud?
It would depend on if you’re able to upload the file to that directory or not. If you can find a way to do that, then you should be fine.
2 Likes
It’s possible for some…
1 Like
for now
1 Like
Does anyone know what setting the KineticUseFileSystemNotDB = false does specifically… I ran it because a couple conversion tasks on upgrade failed because it wasn’t set to false. Now all my dynRpt kinetic apps aren’t around and they need to be regenerated… at least that’s what I am thinking happened. Does that make sense?
Different way to ask my question here… I regenerated all my dashboards and DynRpt kinetic apps after the upgrade and then I ran this KineticUseFileSystemNotDB = false conversion like a week later. Then people went in to do UAT testing and they can’t open any of the dashboards or reports until I regenerate them again. My question is, did I do that to myself by running that KineticUseFileSystemNotDB = false conversion? 
As far as I am aware, the KineticUseFileSystemNotDB setting effectively just makes the Kinetic MetaUI framework load and update MetaUI files from the Apps\MetaUI\ folder rather than the Ice.XXXDef table.
Regarding changing the setting from True to False, then False to True, I would suggest only doing that with a lot of caution. It is relatively easy to have changes and or components overwritten or lost given how the file system and XXXDef files and records are effectively independent from a primary source perspective.
The MetaUIMigration process can be used to upload file system files to the XXXDef table but given that this process effectively deletes and re-uploads the ‘System’ loaded definitions, it can result in previously uploaded then modified Kinetic UI changes being lost. There is some workflows and alternatives to mitigate and workaround such challenges but overall, my suggestion would be to use the default KineticUseFileSystemNotDB = false setting across all important environments. Particularly as Epicor continues to refine and change elements of the framework which could lead to other/future issues with non-standard configurations.
PS: While the Application Studio Export / Import functionality seemed to have quite a few issues earlier on, my recent experiences using it have all been great. I would definitely test and validate it within your own environments, but I have found it a great and easy method to move Kinetic UIs between environments with different KineticUseFileSystemNotDB settings.
3 Likes
Just regarding your specific scenario, when you regenerated the dashboards and report definitions with KineticUseFileSystemNotDB = true, they would have been generated only in the file system.
Therefore, once you changed back to KineticUseFileSystemNotDB = false, the system would not have found the MetaUI definitions within the database. By running the MetaUIMigration Conversion Workbench process, you have could have had the system load them into the database but as per my post above this, that can potentially lead to future challenges and issues such as future lost changes so I would suggest a good review and some caution when making changes going forwards.
Personally, I would be inclined to backup/export everything and rebuild the MetaUI folder with just the OOTB standard Kinetic files and then rebuild/reimport all custom components with the KineticUseFileSystemNotDB setting set to false.
2 Likes
Thanks a ton Callum, I’m not sure how to “rebuild the MetaUI folder,” but thank you for your help.
1 Like
There’s lots of options and methods to effectively rebuild the MetaUI folder, but I think that the easiest and safest would probably be just to replace the current MetaUI folder with a copy from a fresh/clean install/instance.
2 Likes
I can see this is easy but is it the safest? Yes, there is a MetaUI folder on the server, but isn’t it built from the database? When we copy one instance to another, the instructions don’t say to copy to the MetaUI folder too. We restore the database and the MetaUI (and BPM folders, etc.) are rebuilt. I can see how copying the folder would get one out of a jam, but if the folder and the database are out of sync, as you mentioned above, won’t that catch up to us at some point?
1 Like
Yeah Mark I also am confused about the architecture here and what dependencies or relationships there are between MetaUI folder and the DB. Maybe we can pick an architect’s brain at insights.
The default configuration is KineticUseFileSystemNotDB = false. Meaning that the system uses the MetaUI source files within the Ice.XXXDef table. Within this configuration, the File System copies are only used as a source to populate the base/standard Kinetic UI forms within Ice.XXXDef tables via the MetaUIMigration Conversion Workbench process. And custom/customized forms only exist within the database meaning that there is no need to copy the MetaUI contents as the folder should only contain standard Kinetic and partner solution/SDK forms.
When the configuration is overwritten and set to KineticUseFileSystemNotDB = true, the system sources, creates, and updates the MetaUI files at the file system level. Meaning that with this setting it is important that the files are regularly backed up and they have to be copied between application server folders, or specifically migrated via export/import processes, to be migrated between environments.
When the settings are changed, naturally it can lead to a couple of problematic scenarios where files are mismatched between sources and in the case of changing from KineticUseFileSystemNotDB = true to KineticUseFileSystemNotDB = false, it can result in there being non-standard MetaUI files at the file system level which when the MetaUIMigration Conversion Workbench process is run, can result in changes being overwritten.
Ultimately, I would not be changing the setting from the default KineticUseFileSystemNotDB = false value unless one has a good reason to do so and then only within a dedicated single application server development environment.
Please note: I do not work for Epicor and have not been told by Epicor specific information regarding this, but it is what I have observed and learnt via testing and experience. And please always remember that undocumented development features such as this can often be subject to change at any time without notice. For example, a logical next step might be for Epicor to move base Kinetic UI form definitions to the common database similar to how they have done so recently for standard SSRS report definitions.
1 Like