Session Property to indicate App Environment - Production DB versus Test/Dev DB

APM feature Request???

2 posts were split to a new topic: Change Environment Color based on Instance

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.

1 Like

A post was merged into an existing topic: Change Environment Color based on Instance

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.

Session.IsProduction

Maybe it’s all just wishful thinking.

1 Like

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.

In regular BPM I could just use

return db.EntityConnection.StoreConnection.DataSource.ToLower() == "productionhost" && db.EntityConnection.StoreConnection.Database.ToLower() == "myproductiondatabasename";

in the custom code action in the Condition widget to accomplish the same thing but I like my code in one place.

1 Like

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

Side note for posterity: A workable solution but I would recommend NO ONE EVER DO THIS.

This works the same would be much more friendly to upgrades no custom dll recompile required not messing with ErpContext object



image

3 Likes

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.

1 Like

I second this, this would be amazing.

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?

https://www.businessinsider.com/why-too-much-choice-is-bad-2018-10

1 Like

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.

1 Like

Under Consideration - in 10.2.500

2 Likes

Potential Solution spotted in the Wild! 10.2.500+

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

THANK YOU @Edge!!!

5 Likes

That’s a good start… But still can’t identify the actual environment.

And from what I’ve heard some folks have separate TEST and DEV environments.

I Second that @edge May 1000 elephants fertilize your pumpkin patch with their droppings. That’s awesome, we’ve been doing it via Code Blocks for years. Woohoo!!!

I have a DEV, TST, TRN, PRD, EDU – all seperate Machines, Seperate IIS Instance, same Names like “EpicorERP” and I use the Server Name to Determine it via Code, for the time being.

Previously where I worked we prefixed the Servers with PRD-APP1, PRD-RPT1, DEV-APP1 so I only needed to use .Contains() but at my new job they are random names, I started to use alot more Checkboxes on Company Configuration to Enable/Disable something. So when we do a DB Copy I just run the SQL to uncheck those Columns.

1 Like

Tangential to IsProduction, I noticed Company Maintenance also has an “Is Live” checkbox.

image

1 Like

In the web.config of the server instance, you could just add a custom appSettings key/value to indicate what environment you’re in, and then access it from a BPM by using:

var customAppSetting = System.Configuration.ConfigurationManager.AppSettings["CustomAppSetting"];

We do this with logging level and environments and a few other things.