Anyone know of any issues running Service Connect 10.2.400 with ERP 10.2.600?
Hi Chadd,
Yes.
SC prior to SC 10.2.500 fails to import .NET assemblies from Epicor ERP 10.2.500 or newer with:
<Error>
<Descr>Ambiguous match found.</Descr>
<Method>System.RuntimeType.GetMethodImpl(String name, BindingFlags bindingAttr, Binder binder, CallingConventions callConv, Type[] types, ParameterModifier[] modifiers)</Method>
<Exception>System.Reflection.AmbiguousMatchException</Exception>
</Error>
I have to mention that SC is backward- but is not forward-compatible with Epicor ERP.
That is, excluding Epicor ERP updates, SC version should not be lower than that of Epicor ERP, or in other words, you need SC 10.2.600 or higher for Epicor ERP 10.2.600.x.
@AMS - Would you upgrade your existing SC install or do a new install if going to 10.2.600? I’m leaning towards a new install on a new VM. So that our old SC is untouched.
Not the same person, but we’ve always done a new install on a new VM so we can test the workflows prior to go-live without affecting the old SC server and workflows. We export our workflow and connection data from the old SC server and import into the new server. We went from 10.2.300 to 10.2.600 this way.
1 Like
We managed to forget about our SC deployment till now. So it’s going to be an on the fly test/migration… 
We are going live on 10.2.600 this weekend. I was figuring a new install of SC so we could export/import and “test” without breaking the existing SC install.
Better to remember the Friday before the migration and not the Monday after. IIRC, our SC workflows migrated mostly painlessly – the biggest issue was reimporting the Epicor references and double-checking that everything still lined up in the workflow .NET calls.
Truth. I think we will be OK… we have till Monday to make it work 
I’ve heard that SC now does REST. If true, that would eliminate that issue, no?
I agree with Tyler - if there’s a need to be able to switch back to the old SC installation (or to do preliminary testing on the new version prior to fully switching to it), then installing on a separate VM sounds like a better choice than, say, taking a snapshot of a VM and reverting to it in case of troubles (snapshot would not allow for running both versions in parallel, obviously).
New VM would also allow for newer OS (and also the need to set it up with correct permissions, windows components, firewall rules, etc).
I would, however, mention that when installing on the new VM, you have two choices (and I am listing the steps I can think of not to scare anyone off).
Forward notes:
- If you have BPM directives or UBAQs calling SC from ERP side, and the new SC install will be set on the new machine name, remember to retarget them to the new SC installation.
- Upon upgrade of SC to the new version, you need to re-import references (.NET/Web/REST) - this is because as SC progresses, its reference code and config generation evolves
- Upon upgrading of ERP to a new version, you need to re-import references (.NET/Web/REST) pointing to ERP - this is because the structure of the data ERP accepts/returns evolves (and for .NET references to ERP – you need the client to match ERP)
-
New installation with a new database, then restoring the Connectivity backup, then reimport of all references (needed when you update SC version), then possible additional setup of the installation in respect to parts not covered by Connectivity Backup like users/groups/rights(covered by security export-import except for passwords)/log/document tracking archiving/etc.
With this variation, since you do not transfer the database, you lose document tracking left on the old install. -
New installation over a copy of the existing database, then troubleshooting of the result, then restoring the Connectivity backup (you still need those SC workflows), then reimport of all references (needed when you update SC version), then possible additional setup of the installation in respect to parts not covered by Connectivity Backup & DB like log/document tracking archiving/etc.
With the variation#2, the complicated part is cleaning up the database from references to the old installation name (thinking of it, maybe cleaning should happen right after copying and before installing SC) – this is needed because the copied DB would contain mention of the old SC server name in three tables.
Couple more alternatives I can think of, just to lay out possibilities:
-
(if Windows installed on the VM is part of the domain, make sure to disable domain password change in that copy of Windows - otherwise if you are unlucky, reverting the VM back may require you to re-add to the domain; this happens if while you were in the “new” copy, Windows changed the password for the computer account in the domain) Shutdown the VM, take a snap shot, start the VM, upgrade in place, re-import references. In case of trouble – revert to the original snap shot.
-
[Prior to following this path, check that it is in line with Windows OS licensing]
(if Windows installed on the VM is part of the domain, make sure to disable domain password change in that copy of Windows - otherwise if you are unlucky, reverting the VM back may require you to re-add to the domain; this happens if while you were in the “new” copy, Windows changed the password for the computer account in the domain) Shutdown the VM, clone it (this will keep the name of the machine), upgrade in the clone, reimport references, test. The downside is that you will not be able to run both new and old VMs at the same time (Windows will complain about computer name conflict on the network)
1 Like
It does, and migrating to REST is on my back burner…way in the back, like 5th row back. We’re in the middle of bringing one of our child companies online in Epicor so once they’re live we’ll be able to revisit some clean-up tasks like using REST more and migrating a lot of our BPM logic into Epicor Functions.
Indeed, SC allows importing REST references from Epicor (SC 10.2.600 added support of REST v2; couple of versions before that got REST v1, IIRC), however when calling custom methods (as opposed to UpdateExt), adjustments may still be needed if a field required by the call was added between versions, and it is not transferred in Conversion created at the time where the field was absent.
Good thing about REST is that you do not need to keep matching client assemblies imported as .NET references to the version of ERP installation.
2 Likes
Good to know. We tend to upgrade slow here because of SC and updating the references always seems to break things and with REST, only signature changes would break things.
It sounds like option 1 is the better way to go? As there is less cleanup of old references and such.
Yes, I believe of the two options, the #1 is a better one.
You will need to transfer the setup not covered by Connectivity backup manually (and document tracking activities/tasks created in the old installation will not be in the new install).