Cool publish was already accounted for in the query above and private didn’t show up in mine good to know!
however I believe Private is just for Internal Only Checkbox that shouldn’t matter, either way awesome!
yeah it was in yours I see now, appreciate the help
1 Like
That’s all well and good, however, how about those using widgets?
Surely, there needs to be a way to at least view the function details.
Surely, there is. Source code belongs in a source control system with documentation about what the code does and how to install it in a repeatable, consistent, and reliable method - preferably automated. It’s a mind set that is popular with freshly-branded coders. Hell, you can’t get an interview as a coder without a public code repository. Developers aren’t allowed to publish to production. They create their artifacts and start an automated process to install them.
My point is, there are times Epicor should change but, just maybe, there are times we need to change. 
1 Like
Assuming there is only ONE single methodology that everyone uses, or trying to enforce it, is counter productive. I understand WHY Epicor did it that way. It’s for their cloud environments. It’s just about restricting users from entering code in cloud environments. Not against it, but there should be a switch that can be set in the config to disable this behavior in on-premise installations. Development environments get refreshed every few months.
Also, I have asked multiple times for Epicor to add some events I can hook in to actually be able to use proper version control. Still no plans for it apparently…
Just one more reason to never use Epicor Functions, honestly… Can’t call functions in the same library, can’t call functions from client code without littering it with usernames and passwords, and now can’t include them in solutions, which we use to publish EVERYTHING ELSE. The more I look into Efx, the more I understand it’s a half baked solution.
I understand why they did it, but I don’t agree that “this is the way”. It’s at best a poorly thought out implementation issue.
1 Like
That’s all well and good, but it was Epicor’s idea in the first place to store ALL their code in the database…
You can do this in client code without user names and passwords by using the RestClient helper that is built in to Epicor 10.2.700+ it uses your current session to make the calls.
2 Likes
Awesome, do you have an example of its usage documented somewhere?
While we’re on the topic of source control…
For BPM’s, you can see the history in the server->BPM folder. Where are the sources for these functions stored?
1 Like
I wonder when this made it in, been asking for months in preview program meetings for a BO or something to be able to do this… Thanks!
1 Like
This was released with 10.2.700.0
3 Likes
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.