MetaUI dump sources?

Kinetic ERP
1

Is there a Dump Sources equivalent for MetaUI json? Meaning Custom Layers?

2

I’m not sure it’s needed anymore?

MetaUI used to be hosted in the filesystem, custom layers, etc.

It’s since been migrated to the database in XXXDef, off the top of my head Key1 is KNTCCustLayer and Key2 is the app name, Key3 the layer name. and key4 the relative file path of the particular .jsonc (so there’d be multiple rows per each app, for events.jsonc, layout.jsonc, etc.)

The json itself is in the Content column, so you should be able to fully extract an app’s json with a BAQ.

1 Like
3

Thanks Gabe. I understand that it’s plain json in the db. Just want to grab source text off disk for scm and let epicor keep the extract io responsibility if they’re doing so already as is the case for dump sources (Functions, BPMs).

4

Conversion #191 in Conversion Workbench that runs every release/update pulls MetaUI from disk into db, I think Epicor pulled any sanctioned access method for these files from the filesystem, and did not provide an equivalent dump sources.

Although, if conversion 191 works as designed, the database should be considered authoritative for any records marked IsSystem = true :wink:

2 Likes
5

There was a Database column where you could tell it whether to use the Database or File.

When I set it to file it will write my Layers to Disk, and when I make changes on Disk (testing something) it will use it.

It was helpful for debugging, playing around… Not sure if it was in Local001 or somewhere.

EDIT:

SELECT * FROM Ice.SysConfig WHERE Key1 = 'KineticUseFileSystemNotDB';
1 Like
6

Thanks. Yeah my understanding is

means running from filesys. I’m looking for running from db but dump db to filesys.

7

You will probably just need to read:

Ice.XXXDef WHERE TypeCode = 'KNTCMetaUI'

It has the Path, Contents etc in there… then write to disk yourself

1 Like
8

Thanks. I understand. Just checking to see if this is a thing so we don’t have to recreate the wheel and take responsibility for something epicor already has built. For example, no need to get function/bpm code from db or decode fields from rest because Dump Sources is a thing.

Edit: in theory it’s a thing cuz they do it when you switch to UseFileSystemNotDB. Hmmm

9

Of course, if the source was kept in an immutable text format with all of the versions in a single place…

10

Indeed. Well getting out of db is first step to getting into git so…

11

The funny thing is that I have it on pretty good authority that Epicor already stores these files in source control. Even Epicor starts with source control and then loads the MetaUI into the database! :rofl:

12

Honestly, I’m not trying to be an :peach:, it comes naturally. :wink:

I see a difference between a single source of truth in the Main branch verses a clone of the truth stored in the database, or even a clone of the clone stored in the file system.

1 Like
13

I don’t disagree. Yet here’s the thing. We either progress under the current state of affairs or we sit n wait for 139.

I say the former. Let’s do it!

while also utilizing any prebuilt features we can avail ourselves of. Thus keeping the responsibility on epicor as much as possible.

1 Like