Add the ability to call ContextLibrary classes in custom code. Like Erp.Internal.LibFindPart and Erp.Internal.Lib.CalendarDate. There a handful of helpful Context Bound classes.
Not sure if this was implemented or not but add the ability alias assemblies. Currently, you can’t use two services with the same Table signatures such as the SelectedSerialNumbersTable.
Add the ability to copy a Function to another Library or list a Function as a template and then have the ability to create a function from a Template function.
I agree with all the modal comments, sometimes I have to have two instances of Epicor running so I don’t have to close the designer all the time to lookup or trace things.
I agree with VS Editor or just a formatting tool to prettify the code.
Add the ability to Group Widgets so the group can be used on more than one result row after a condition widget so you don’t have to use custom code to loop through. Or even if it was only the Function widget that had the ability like the custom code/email/autoprint widget in a standard directive. Maybe there is a solution that exists that I’m simply missing.
It is the limitation for the Tuple<>-based version of the InvokeFunction method.
There is another overload of this function. Something like object InvokeFunction(lib, func, object args). Array-based overload works for cases covered by Tuple<>-based one too.
You can try to call a function with more than 7 in or out parameters with widget and look at generated code.
Tuple<>-based overload was implemented for performance reason.
Also, if you think about named tuples, then they are value types, so they are very inefficient in our case.
I’ll start a new thread on this since it is tied to the ability to use DevSecOps practices for ALL Epicor customizations.
But briefly, I would want to store the same information that one would get in an BPM/EFx Export. I understand that with EFx, we might have to rely on encrypted artifacts for functions that are distributed by 3rd party providers but that’s a whole other version management issue.
It is mostly impossible. Compilation errors (when you save enabled directive in maintenance UI) come from C# compiler.
In general, directive validation should cover your needs. But it should be improved definitely.
They only look similar. But they are completely different sub-systems. Anyway, the new UI will use way different approach.
I thought about this approach. The main “blocker” is targeting. Existing import/export UIs cover both MD and DD. Putting them into the action menu conflicts with this behavior.
Also, I’d prefer to completely remove Import/Export from BPM in favor of the new solution workbench (if and when it will be ready).
In general, it is possible already (if you have a group and select overwrite mode).
However, I understand what you mean.
There are two problems here:
Since BPM does not support company mapping (how it is implemented for EFx), copying is the only way to use same directive in a few companies. And it makes overwriting much more complex. Especially since directive name is not an id and can be changed in one of the companies.
I have a few ideas how to improve that, but no ideas how to migrate existing environments.
In such a case, you already can do that via REST calls. A few years ago I created pretty stupid PowerShell scrip to import EFx libraries for our auto-test team.
So such approach allows to export and import EFx export packages. Moreover, in the case of export/import (in contrast with installation), you can specify non-binary format.
BPM is harder. If you have no BPM forms and Hold Types associated with your directives, you can do similar thing (but in old format - compressed DataSets).
That’s exactly how I would do it. That’s all I would add to the forms, a menu item to export as JSON and just make a REST call to get it. It would be just like the Azure Portal…
It’s a quality of life thing. Often time I find myself wanting to copy something I’ve done in another function in a new function. I usually use the custom code widget so I can see all the code right from the main window without even having to demote the library. However if I want to see the using references for that code I have to demote it and then open it and click one tab over just to see it. If it was on the main screens tab like everything else then I wouldn’t have to do all that just to see what usings are being used.
I agree wholeheartedly with Matt on this one. You shouldn’t have to change the functionality (demote the function) in order to inspect it. If you’re trying to debug something, or recreate an issue it makes it more likely that something is going to get messed up by demoting the function when you don’t intend to change it at that time. And there are many times when you want to look at something that is working to use on something different, like Matt said.
You don’t need to promote library to test/debug it. It works in BPM in the company where you created the library.
Also it is accessible via REST (but not in the help page).
Main difference is in additional segment (/api/v2/efx/staging instead of /api/v2/efx)
AFAIR, all above is documented.
Promotion is for production/qa environments mostly. Not for development one.
I get that. But it’s usually not that clean in the real world. We just think that a read only ability to inspect functions when they are promoted would be useful. I get not being able to change things, but to not even be able to see them is annoying.
And to be clear, this is a “nice to have” request, not a necessity. It would just be a time saver.
You should remember, that EFx is not for customers only. It is for partners/CSG/CSF/etc too.
So, stuff like that cannot be demoted and never will be available to read.
I will play with an idea to relax this restriction for imported/created libraries, but it definitely never will be possible for the installed libraries.
There really should be a setting for that on the library to encrypt it, not just if it’s installed using the solution workbench. We use the solution workbench all of the time in order to move a whole package from dev to production (like we are supposed to) but the fact that this locks the functions means that we can’t use the solution workbench for functions. If we did, then refreshed dev with a copy of production, we can no longer update our own functions. So a checkbox for partners to use that locks the function on installation would be extremely helpful.
