We are upgrading Kinetic from 2022.2 to 2023.1. We know we need to update all .Net References in Service Connect after it is upgraded. Does anyone have a faster way to import updated .Net references other than one-by-one? Maybe by editing the .config files on the server in some way?
Hi @aschickedanz ,
I believe there currently isn’t a direct option available for what you’re seeking.
As a workaround, I recommend taking a backup of all workflows that contain .NET references during the restoration process, The system will prompt you to set up a new reference path in grid format, which is straightforward to alter. Additionally, you will be asked to provide the file path and your user password once. This method should provide a solution to your problem.
Regards
Dnyanraj Patil
Thank you for the suggestion. We are doing an in-place upgrade, so I do not anticipate restoring any workflows. If there are no other suggestions, we will consider it.
Thanks again,
If you don’t mind my asking. Did you have to go through and update each individual conversion when you upgraded? I am facing the same thing: Going from .NET refs to REST. My fear is I will have to “re-wire”/redo every conversion after I pull in the REST refs… Considering how many workflows we have, I have the fear…
What are REST refs? .NET has DLLs but Epicor REST is done via https. There are no references. I heard that Service Connect can do REST but I’m not sure if it uses OpenAPI/Swagger at all. Generally, since REST does not need the underlying logic, there aren’t any references required unless the calling signature changes. But I defer to the SC experts on this one.
1 Like
Hey Mark! Thank you for the reply that many moons ago. I was incorrect. SC can still use the .NET refs directly in Kinetic. No absolute need to use REST.
To anyone else who has upgraded from E9/E10 to Kinetic and still use Service Connect: Is the general methodology for upgrading to simply point to the new dlls, test and fix errors? I am looking for someone who has done this before that can explain the general process. Trying to gage how time-consuming this will be. Thank you!
Just an FYI
1 Like
When (if) Service Connect is retired, I would sincerely hope there will free conversion of existing active workflows to the replacement platform
2 Likes
Thank you Mark. I agree we shouldn’t make a new SC solutions for Kinetic and forward, but what about existing? I mean, there are organizations out there with many complex SC solutions that took a lot of time to build. If you can “plug” them into the Kinetic .dlls and still run them, why not?
That being said, I think you posted that because I said “No absolute need to use REST.” My statement was incorrect according to your link to Mr. Shoemaker’s statements, thank you for highlighting that. I don’t want to mislead, so I struck that out in my post.
When the .NET Client is no longer shipped, where will you get those DLLs? 
Even now, people are reporting a different call signature for REST than the equivalent .NET client.
You may want to take Tim’s advice and convert those calls to REST. Doing so earlier will make moving to another solution in the future less work.
1 Like
I believe that the replacement platform is Automation Studio. Automation Studio is cloud-based and utilizes REST for all the Kinetic connections. I think you’ll need to rebuild your SC workflows as Automation Studio Recipes.
I assume you mean do that with Automation Studio and dump Service Connect entirely, or is there some way to use REST in SC?
Yes, and I think Tim mentioned that in his post.
Automation Studio, PowerAutomate, Azure Logic Apps, PowerShell Scripts, C#/Python/Go/Javascript, and many other tools can orchestrate REST calls.
1 Like