You can also see the Source Code of functions in a folder like you do BPMS. This is configurable in your sysconfig file (also in the Epicor Help)
2 Likes
Thank you. Your encyclopaedic knowledge continues to amaze me. Time to go back and re-RTFM.
3 Likes
haha yeah the FM has grown quite a bit… I’m having to do a lot of reading too
–Cheers
2 Likes
Be warned the scaffolding code they use heavily sandboxes the code and isn’t easy to read for debugging purposes, but it’s an ok solution if you just want a backup of your own code…
You’re right, but it’s better than nothing. Would also mean the issue of recreating a function from scratch is somewhat nullified. Especially if you’re using a code widget with your own code, it will be there verbatim.
Agreed. But at some point they have to right? Otherwise, how could one backup/restore an environment or rebuild BPMs/Functions? I think we as users made the decision to rely on that storage, which frankly is on us. The same can be said for SSRS reports with Microsoft. They store the reports but if that SSRSDB is corrupted in some way, the user loses the reports even though we may have had access to the RDL files at one time.
This is one of the main reasons I have been pushing DevOps practices up on the Idea list.
Where BPMs and Libraries are really stored.
As for source control, I’ve had an idea for a couple of years now. We can retrieve EVERYTHING in Epicor with REST. Kinetic depends on it so I don’t see that changing. You get a nice big fat Json blob for BPMs and Function libraries. These text blobs will store well in Git which means each version of a customization with have its own hash ID. Now we have a way to upload this customization and add the hash ID to the title programmatically to know exactly which version of code is running in Epicor. Formatting the Json properly before placing it in Git would give users the ability to actually get a diff against changes too.
And using REST here is important because the same processes for gaining access to source (instead of looking at server folders) works for cloud environments as well has on-prem environments . It also works where the Ops team wants a clear delineation from the Dev team, i.e. SOX controls need to be in place to prevent direct updates to production by the Dev team without some review.
What I want from Epicor is to provide the automation tooling that promotes DevOps ideals (mostly done) and for them to adopt these ideas in their own practices and promote these processes with the user base.
DevOps consists of people, processes, and technology and the hardest to change is always the first one.
2 Likes
Jose, you are pushing me to encrypt the whole EFx info…
You can also see the Source Code of functions in a folder like you do BPMS
Just as a reminder… Neither BPM nor EFx generated C# code can be treated as a “source of truth.” So, putting such artifacts under Version Control has no real value. The actual sources are the metadata stored in the DB. Code generators can be changed anytime without public announcements.
Haha come on @SAD why does it stop you from modifying your own function when installed via solution workbench?
That seems a little silly no?
- Dmitry left the company last fall
- Olga never had relation to EFx
Regarding main discussion…
No, it is not absurd. Solution is the way to INSTALL something. Transition from the pilot to production is not installation actually. Unfortunately, we have no separation of concerns here, so solutions are used for both purposes. Inability to import (instead of to install) library with SW is the temporary limitations rooted in inflexibility of the SW itself. Wait for the announcements about new release.
In general, I already answered that :). Don’t use SW in 10.2.700 to roll out your libraries to the production environment. Just use import. Moreover, SW in 10.2.700 does not support multiple libraries per solution, so it is much easier to roll out them with powershell scripts and REST (ImportLibrary method of the EfxLibraryDesigner service).
Also, imagine C# console application that you are developing. When you install it, you don’t install sources, only binaries. And if you want to update the app in the production you just change, build and repack it on dev machine, and only then you install it.
In our company we must oblige by Segregation of Duties. So SW is the easiest way to train the Production Support team to deploy something. We dont do any development in PRD, we dont even have access as devs… So deploying them via SW is not a problem as we never will make modifications in PRD.
However once every 3mo PRD is copied to DEV, TST, QA and they are overwritten with the latest data from PRD - would that mean the EFx then would become readonly in DEV?
Haso I believe that is the case , since they were installed using the SW into PRD
1 Like
Yes, it would. I don’t like the idea to use the main Epicor DB as the storage of “development”-related data (BPM/EFx/etc), but I failed to push the approach with separate storage for “customization” sources.
I would suggest to include script exporting all libraries before replacing dev env with production data.
Alternatively, you can use bcp to store all actual Ecf.Efx* tables and then apply data back. Except the case when you have both your own and 3rd party libraries.
1 Like
Or you’re an Epicor SaaS customer… 
Actually, when you install C# console application you do install SOURCE. IL source. Which is compiled to binary at runtime. But that is beside the point.
Solutions have been used for deployment for years through all previous Epicor versions. Databases have also been copied to create dev environments for as long. There is no reason the rules should change now.
This is clearly an issue, and claiming it is a design feature is ridiculous. Someone either didn’t understand requirements, or did a very bad job at implementation. Call it what it is, don’t rewrite history to claim it’s all peachy… It’s just a poorly thought out implementation.
2 Likes
I can’t imagine how the schema with PRD replacing DEV/TEST/QA can work for SaaS customers.
Probably it works, I just can’t imagine how 
It depends. At the first place IL source is not a real source. Then it can be obfuscated. And finally you can use AOT compilation and roll out native image.
These are too thought words. It is just not interesting to me to communicate in such a form in my personal time.
1 Like
Fine, then communicate it in whatever form you prefer on your professional time. The point is this is an issue, and acknowledging it is the first step to fixing it.
I’m not support. My professional time is for different activities.
3 Likes