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


(Caleb Grundmeier) #1

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.


(Jose C Gomez) #2

It’s already there

appserv = Session.AppServerURL.ToString();

(Pierre Hogue) #3

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?

pierre


Change Environment Color based on Instance
(Caleb Grundmeier) #4

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.


(Haso Keric) #5

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.


(Caleb Grundmeier) #6

APM feature Request???


(Jose C Gomez) split this topic #7

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


(Jeff Gehling) #8

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.


(Jose C Gomez) split this topic #9

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


(Caleb Grundmeier) #10

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.


(Caleb Grundmeier) #11

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.


(Jose C Gomez) #12

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


(Joshua Giese) #13

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


(Caleb Grundmeier) #14

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.


(Jeff Gehling) #15

I second this, this would be amazing.


(Brandon Anderson) #16

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?


(Jeff Gehling) #17

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.


(Caleb Grundmeier) #18

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.