Epicor Function Practices

I have a quick question for you all…

What are your best practices with regards to Functions i.e. creation/usage/any conventions?

Say for example I am working on a function and I promote the library to test it, but then another developer wants to work on another function inside the library. They no longer can. How to get around this?

Do you create libraries on a per screen basis?

Any suggestions would be great!

This is just me, and it’s a hill I’m willing to die on but, source code does not belong in the database for this very reason. I understand Epicor’s view on this. Most of their users are NOT coders and DevSecOps is difficult to do with Low/No environments.

Ideally, from a security best practice, Dev should be done in a Dev environment and shouldn’t be done on production data. I know, that’s a whole new problem to solve.

Unfortunately, the “Promote to Live” process encourages people to develop in Live and not a Test system and makes it difficult to have multiple people working on code. Yes, there are a lot of single resource shops out there but they work with consulting houses which leads to the same problem.

IMHO, it would be a competitive advantage if Epicor could work good development and security practices into the low/no code world.

5 Likes

Without the ability to use powerful and familiar tools for development, source control, debugging, and unit testing, putting complex business logic in EFX is a complete non-starter. And the usefulness of EFX for small, reusable pieces of code is severely limited by the fact that configurators can’t call them.

1 Like