We have been working with Salesforce for awhile now and I’ve appreciated the fact that when they create a “Sandbox” for you, the field IsSandbox on the Organization object is set to true. I don’t have to do anything and can use it in code to do this or that depending on the environment. And I can’t change that field.
It would be nice if there is a way that the App Server could have a flag that the Session object could pick up that would indicate what Database environment it is connected to. I get that we could probably make our flag somewhere in the DB and set that when we reload a DB but I would rather set it at the App Server level in case someone forgets to reset it in the DB.
We changed the company names in each env to indicate ***TRAINING jan 2 2019 *** in the training env having a copy from a backup of the date specified, from the prod env. We do the same with TEST.
We do this every time we restore from prod.
Then we make the company show on the bottom of each screen.
PLUS
Whenever I do a customization, in addition to the customization name showing on top of the form, I add the environement if NOT prod… so TRAINING or TEST would show up… I found it a better visual…
One thing I would love is the ability of a color scheme being different depending on the environment… So blueish for TEST and Greenish for TRAINING for example…
Moreover…I find annoying the restrictions (we are multiple plants setup (2) ) for jobs or else you right click on a jobnumber and select to use JobTracker, and you get non-existent error… because not in current plant…well it is a tracker… why not allow access…a tracker does not allow any mods to be saved…so at least a color scheme available to distinguish between plants would be helpfull…even having a message indicating: Unavailable, would you like to change plant? or even better, change to the valid plant automatically ?
We are on 10.0.700…maybe the latest versions have all improved in these areas…? Otherwise…nice to have?
I understand but we still have to put logic in to determine if the Apps Server is Production or not. A flag would but much easier to maintain than hard coding all our production app servers urls. I don’t like the idea of having to compare this to that to determine if it’s Production or not.
Just give me a yes or no to look at.
We do use that property a lot in our email subjects though.
Would be good because I have some Conditions in BPMs that Fire off an email… But its also set to
Environment.MachineName.Contains(“PROD-”) – for example I don’t want ACH Notifications or Payment Notification to be sent if we are not in Production! Yeah I could DB copy and overwrite all emails, could be done via your Powershell. So I guess perhaps not a bad Idea “Sandbox” true or false =) Stil would fire off an email if you sent an Invoice to APM =) so not fool proof.
I am currently on a quest to remove ALL HARD CODED ENVIRONMENTS in our bpms and program customization using the session options and parsing the final application name.
We name our app pools: Epicor10TEST/LIVE/PILOT
so I parse out the whole url and get only TEST/LIVE/PILOT out of the end of the url.
I use these especially for our outbound EDI file generation bpms as we dont want files going to the warehouse if we are in our test environment, so we have folders named the same as the app servers.
So when I move a bpm from dev to live I can rest assured I dont need to go in and manually change the folder path in the code.
Sounds like there are various paths to accomplish the same thing. Parsing, Renaming, Filtering on computer names and such. All seem cumbersome(no offense, I’m probably going to end doing something similar). I’m just looking for a one liner.
I ended up just making a small extension class/dll, that I’ll have to reference in our BPMs, that looks at the Connection String to determine if it is our Production Database, which is really the important part. I really don’t care what app server the Session is using as long as I know what database it’s connected too.
So after adding the dll as reference in the BPM I can use return this.Db.IsProduction(); in the custom code action of a condition widget.
namespace EpiHelpers
{
public static class EpiExtensions
{
public static bool IsProduction(this Erp.ErpContext db)
{
var result = db.EntityConnection.StoreConnection.DataSource.ToLower() == "productionhost" && db.EntityConnection.StoreConnection.Database.ToLower() == "myproductiondatabasename";
return result;
}
}
}
Of course I wouldn’t have to have the code in an external DLL but I also have other external BPMs that can use now too.
Why create a Custom DLL and have to maintain and host it? When the info is available directly in the session.AppServerURL ?
I mean what works works, but seems like over kill… and something that is version dependent you’ll have to upgrade that DLL on every Epicor upgrade etc…
you could just do
if(this.Session.AppServerURL.Contains("Live")) //Change to your Production App Server Name
//Do X
To each their own I suppose but having to maintain and upgrade a DLL seems excessive
I understand where you are coming from. I could still use that logic but I would still put in one place so the “AppServerName” doesn’t have change in every BPM that it is used if we do an upgrade and/or change the App Server Name. We only have to change in on place. I guess I don’t like repeating code logic, especially strings that could change. Our database server is less likely to change than App Server too.
I know some advise against external BPMs and references but we have gone through 2 major upgrades without issues. Recompiling is just a step in the process before we give everybody the go ahead. If we were upgrading/patching more than twice a year maybe it would be different. If Epicor had a solution to reuse common code/methods across BPMs, I probably wouldn’t go the external route.
So salesforce forces you into a name (production, test/dev), which is still essentially a string, and Epicor gives you the freedom to call it whatever you want, and you’re mad because you might change it?
I think what the OP means is code reuse built into epicor. If I could write one custom code block to check the environment I am in and reuse it in any bpm, THAT WOULD BE AWESOME. Kind of like a custom code widget repository in the BPM designer.
Salesforce gives you a Yes/No field (IsSandbox) that we don’t have control of. We can’t change it. The name of the sandbox is set by the user.
Maybe digressing a little but I’ll also add when we do a major version upgrade, like 10.1 to 10.2, we built all the App Servers with new Names(which are distinct to the version), along side the current App Servers, ahead of time and pointed them to a practice Upgraded DB. When the actual go live was started we shut down the old App Servers and the Production DB was upgraded. Then we pointed the new App Servers to the Production DB. We didn’t have great luck upgrading the current App Servers so to save us some headaches, we just built new ones and made sure those were hunky dory before doing the Production DB upgrade.
Profiler shows it updates the SysLicense table Ice.SysLicense to IsProductionInstance =1
UPDATE [Ice].[SysLicense]
SET [IsProductionInstance] = @0
WHERE ([SysRowID] = @1)
SELECT [SysRevID]
FROM [Ice].[SysLicense]
WHERE @@ROWCOUNT > 0 AND [SysRowID] = @1',N'@0 bit,@1 uniqueidentifier',@0=1,@1='0F0F9164-880E-4ABE-B8FE-21F9AF7A02CA'
Further more it was added to the BPM Condition Workflow
