You can’t import any BPM’s from the pilot into live, since its a newer version. Copy and paste doesn’t work. So you can either develop the BPM in live… Or try to recreate it after you have it working the way you want in the pilot, but this sort of invalidates the testing since you might make a mistake during the hundreds of clicks it takes to recreate it in the live.
Not a nice experience…
… yes, I tried changing the version inside the ‘.bpm’ file (which is actually a zip file) in case there were no real changes.
That sucks. You really need a development system which is the same as live, and a pilot system to test upgrades going forward. The fact that you are stuck with just 2 and the “dev” system isn’t the same version as live hamstrings you, not to mention really invalidates any testing that you do if you aren’t testing in the same version. On prem for the win I guess?
Wait, what? DevOps you say?. This applies to both cloud and on-prem. Not every company has the big bucks to buy extra dev servers when renting smaller VMs (even free in some situations) for Dev would work.
We’re still “live” in our on-prem E10 database but moving to cloud and it’s confusing to our users to say, “Kinetic Prod is Pilot” when there is also a Kinetic Pilot icon on everyone’s PC. It’s amusing and annoying so I can only imagine how frustrating it’ll be when we are at two environments and mismatched versions.
When we were MT, there was an “education” DB that could they allowed us to use as the “non-refreshing pilot.” Is that not available? And I don’t have a clue what version it would be on (vNow or vNext).
It was one of those things where if you knew to ask for it by its exact name, they were like “Oh yeah of course we do that.” But you had to know it in their terms.
But I’m saying it wasn’t really “education” or demo, it was still your real data. Just older than pilot.
Edit (2): This is the “Epicor Cloud ERP Q&A” from 2016:
I feel your pain. Same here. I had missed the email that pilot was going to be refreshed with Prod Data before the update. I had a moderate sized customization in pilot almost done… Guess what I get to redo it… its gone…
I am not sure how this stands from a licensing perspective, but as a development environment you could stand up a machine with windows 2019 evaluation, and SQL server developer edition then install epicor on it using the education database. You would have to get a licence key from Epicor to do this.
You can pickup some pretty cheap workstations with plenty of RAM and an NVMe and your in business.
The eval editions are 180 days which should give you plenty of time.
Frankly, she’s not asking for enough! I’d like a test harness for directives, functions, including configurator UD Functions so we can do automated testing locally using mocking to eliminate the server altogether.
Yes, please search in Epicor Ideas and make your votes for those items that are important to you. Also, if you don’t see something in Ideas, then create your own idea. BPM (and BAQ and Dashboard and Function call) improvements are one of the things that I am trying to champion, but without your votes, it will not happen.
aidacra
(Nathan your friendly neighborhood Support Engineer)
18
Regarding the additional systems available with our Public Cloud offerings:
Customers can purchase additional environments (e.g. SaaS[nnn]Third, Fourth). These additional environments follow the same upgrade cadence as their Pilot system, however.
There is an additional that Public Cloud customers can subscribe to that would allow one to defer a release upgrade if the timing of the first wave(e.g. All Multi-tenant/Express customers are in the first wave, and all Public Cloud customers by default unless they opt out and have the entitlement to defer). This option was made available to allow our customers to have more control over when these upgrades occur to work around their business needs. This doesn’t change the length of time that non-production systems are at a different release level than production, however.
Why do I think we implemented things the way we did?
This is just a general statement into the ether, and I kindly ask that no one feel that it is directed towards them specifically.
This ~four-week period of time where Pilot is at the newer release is provided to customers so they have the opportunity to validate/uplift their existing business-critical (formerly known as) unique business components in the new release in addition to any business-critical workflow that would cause one to call into Support if it didn’t function as expected in Production after the upgrade. If there are concerns/issues with functionality in the base Kinetic application in the new release, by reporting those to Support, Epicor can do everything possible to have that concern addressed before the production upgrade.
By changing/adding unique business components in Production during this Pilot testing window, one is changing the parameters that go into the upgrade process itself thereby potentially introducing changes to Production that one wouldn’t know until after Production is upgraded–this testing is to see how production will function post-upgrade with the parameters that could impact the upgrade outcome (aka UBCs). One of my IT rules to live/die by: “Never introduce anything into Production if one doesn’t know how it is going to behave”. Unless one knows how it will really behave through/after the upgrade process runs, one shouldn’t be introducing that UBC into Production.
The spirit in which I am saying all of this is I truly feel that the best customer interaction I can have as part of my day job is one that is not needed at all. Speaking as the Senior worldwide Kinetic/ERP Technical Support Escalation Engineer, I would rather sit around waiting by the phone like the Maytag repairman than having a smorg of avoidable P1 issues to keep things interesting. In the interest of full disclosure, while it would be inaccurate for me to state that there weren’t a very small number of decisions/choices made over my tenure here where an alternative approach wouldn’t have more likely led to a statistically less-suboptimal end-user outcome in my mind ( ), the approach we are taking with the Pilot/Production isn’t one of those.
I’m on prem with full control, a half-dozen environments, and 2 TB extra space… and I STILL don’t trust myself this much. Daily work gets exported and saved into my dev repo folder automatically synced to github…
This is all focused purely on the upgrade outcomes/processes, though. While the upgrade outcomes are very important, so is day to day support, testing, fixes, training, and improvements.
Not having a matching Pilot/Test/Development environment available effectively eliminates the ability to try replicating reported Production issues in a safe/non-production environment matching Production.
Ultimately without at least an environment for each of the following, major compromises are being made:
Production - Standard production/live instance.
Test - Same version/configuration as Production. Refreshable from Production on-demand.
Pilot/UAT - User Account Testing (UAT) environment. Can be next/new Epicor version or for new customisation/solution testing between new versions. Should be refreshable from Production - even if/when that does involve the scripted DB upgrade to occur.
. If anyone finds a work around, please share.
I’d like a test harness for directives, functions, including configurator UD Functions so we can do automated testing locally using mocking to eliminate the server altogether. 
), the approach we are taking with the Pilot/Production isn’t one of those.