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
Such as “Product Owner and Solution Architect on the team handling BPM, BAQ, EFx, and REST.”?
Come on now…
When we copy PRD to DEV sometimes we have to Regenerate Schema and there was a time we had to run Directive Recompile. Perhaps there could be a Process like Directives Recompile to regenerate or unlock the EFx Libs. That would probably work for most.
But Its all good info in this thread. I have no problem telling the team to deploy via Import instead of .cab, atleast now that I know that it could lock it up. 
I think ultimately perhaps it shouldnt lock it unless someone clicks the Encrypt Source Code in SW checkbox. Just a thought.
1 Like
This is part of our process every time. It just limits the issues people have during testing of process changes.
@HLalumiere
While I understand you are frustrated, remember we are all here to help each other including those Epicor employees who use their own time to help us out. They don’t have a mandate to be here and help out (none of us do)
So please keep that in mind. If you (we) are unhappy with a particular feature we should take action via the appropriate channels (support / ideas portal) to correct it. Once we have determined that it is or isn’t a bug.
@SAD explained the reasons why it is this way and while it may not be to your or my liking he doesn’t have the power to change that.
You get more bees with honey
7 Likes
Oh, I don’t think EFx was poorly designed. Solution WB, well… 
More and more development for Epicor has been going to 3rd parties: Electronic Warehouse, Super Advanced Project Management Plus or whatever it’s called, and several field service modules. This is being done at the behest of these partners - which is fine for their code. We as users can choose to purchase these add-ons or not. At a time when trust in the 3rd party code chain is under great strain, it seems like bad timing to me. But user-written libraries should have the same control as the 3rd party developers with our own code.
Development and Staging areas are important for testing. Epicor SaaS relies on this ability for upgrade testing after all. This too should be done with PowerShell. SalesForce has the ability to update a test environment from live right from their portal and Epicor SaaS and on-prem users should be able to do so with automation.
Thanks @SAD! I do appreciate your insights. I wish Epicor management was more like Microsoft and less like Apple. It’s difficult for the users to make longer term plans when so little is shared. It’s the one thing I’ve shared with the various interviews I’ve done with Gartner, etc. so I know they hear it. I feel for dev team who has to watch the users struggle with issues and you guys aren’t allowed to say anything. I appreciate you (and all the Epicor peeps like @Olga!) too.
1 Like
I’m using something like the following one. Please note that it is quick’n’dirty solution without error handling
# Disable SSL check
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }
# Load the settings
$settingsFile = Join-Path $PSScriptRoot 'settings.json';
$settings = Get-Content -Path $settingsFile | ConvertFrom-Json
#prepare REST-call parameters
$accessToken = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes("$($settings.userId):$($settings.password)"));
$authHeader = @{
"Authorization" = "Basic $accessToken"
"x-api-key" = $settings.api_key
};
$importUrl = $settings.url + '/api/v2/odata/' + $settings.companyId + '/Ice.LIB.EfxLibraryDesignerSvc/ImportLibrary';
echo $importUrl
#read and import EFx libraries
$files = Get-ChildItem -Path $PSScriptRoot -Filter '*.efxb' -File -Force
foreach ($file in $files)
{
echo $file.FullName
$blob = Get-Content $file.FullName -Encoding Byte
$base64 = [Convert]::ToBase64String($blob)
$methodParameters = '{"libraryPackage": "' + $base64 + '", "options": {}}'
Invoke-RestMethod -Uri $importUrl -Method Post -ContentType "application/json" -Headers $authHeader -UseBasicParsing -Body $methodParameters
}
where settings file looks like
{
"userId": "user",
"password": "password",
"url": "https://localhost/ERP10CC",
"api_key": "real-api-key",
"companyId": "EPIC03"
}
3 Likes