I can open a test configurator in the application studio but I can’t seem to do anything. Has anyone else gotten further ?
(Looking at the help, it seems it should start with a Page1 layout but it does not and I can’t add one)
I dont believe that the kinetic configurator is released yet… it is still in development. Coming soon.
Ah, I wasn’t sure. I would have assumed that except it let me check the Kinetic checkbox and open in the app studio. I would have figured they would have kept those disabled until it was ready to be tested.
1 Like
well, even once Kinetic configurator is released, you will still be able to run the traditional client versions of configurator until you get a chance to migrate them to Kinetic. There is a migration/conversion process that will need to be done for each configurator to make them work in Kinetic.
2 Likes
Yup, I understand that. 
Tim,
Do you know if standard “product configurators” will work in Kinetic, or only those developed using “Epicor Web Configurator”. The Web version is the only one that allows TypeScript code, which I would assume is required to run in Kinetic.
Will tools or conversion programs be available to convert existing configurators to work in Kinetic?
It seems like additional licensing would also be required since Web Configs seem to only be available with “Dealer Network Management”.
Trying to navigate how to approach new configurator projects during this “in-between” time.
Great Question… let me clarify.
There are currently FOUR types of configurator deployments:
- Type 1: the “standard” configurators that work in with the traditional client.
- Type 2: standard Configurator that is “Deployed to EWA”
- Type 3: the EWC Configurator.
- Type 4: The Kinetic Configurator
Type 1 will only run from a client. You MUST be in the client… no options. These will NOT run from the new Kinetic screens because they require the client.
Type 2 will run in both the traditional client (because it still runs the client version, and from EWA, but will also run the EWA version from Epicor Commerce Connect (ECC). When you “Deploy”, there is a process that reads all your C# client side code and converts it to JavaScript so that it is web friendly.
Type 3 is a configurator that will run from both the traditional client, AND from ECC. (I am not sure about running from EWA). When writing your configurator, any CLIENT side code must be written in TYPESCRIPT (not JavaScript). BUT the EWC version is not our forward going embedded configurator. you should focus on Type 4.
Type 4 is the way to go for all embedded configurators. They will be able to run from the traditional client or ECC. There is a upgrade process that will convert the old configurator to a Kinetic configurator. BUT this conversion is not perfect, and you MIGHT need to go in and do some adjustments after you run the conversion. There are no additional licenses needed for running this version. Once it is this type, it will run from Kinetic in a web browser. It will perform better than the old EWA configurator. Also note that any Client Side code can continue to be in C#. There is an embedded tool that allows C# code to be run on the web.
So… “In Between”, if you are not yet on Kinetic, you should continue to develop the traditional configurator, and once you are in Kinetic, you can click the checkbox to convert them.
ONE MORE NOTE: Back in June, we announced the Acquisition of KBMax Configurator. It is a very cool and awesome configurator, and was demoed at Insights (You can see your own demo by going to TuffShed.Com and configure your own shed). Over the next few months, you all will hear about our integration plans and timing this CPQ (Configure Price Quote) module. If you have configurators that you want your customers to run from a website, this IS the future!
2 Likes
I’ve worked with a few different common configurator platforms. KBMax is by far the best I’ve worked with. For any Solidworks users, it handles CAD automation great, but historically had a substantially more expensive cost of entry than options like Driveworks (although, you get what you pay for!). I’m really, really hoping that Epicor is bending over backwards to retain the KBMax experience and culture - that level of quality development over time can only come from a highly functional group.
Honestly, until I saw the news about the KBMax acquisition, I was expecting we’d roll our own Epicor integration and staple it on to third party CAD automation. This is a real game changer for practically any manufacturing sector Epicor users that need configurable orders.
1 Like
John, we are still working out the details on the fullness of the integration as well as pricing structures. It is our intent to keep the fullness of the KBMax experience! Also, we are looking for some people like you who would like to get involved in a Customer advisory board. Feel free to contact me directly at tshoemaker@epicor.com - 949-585-4101
Thanks for the detailed response. I’m currently working in a 2021.1.7 SaaS environment.
How does the setup for Type 1 differ from Type 4? What is the conversion checkbox? Is the “Design in Application Tool” checkbox? If so, I think we have strong nominee for the new worst button to check since “Sync Dataset”.
Once checked, my configurator layout opened from Actions > Configurator, Designer, but I didn’t appear to be able to edit the controls at all. Also can’t edit the controls in the traditional designer, or uncheck the application tool checkbox. Essentially bricking my configurator. This is all test, so no big deal. Just trying to figure out the learning curve.
1 Like
Yeah, that checkbox is a prominent footgun. If someone should happen to actually check that box in production…
Plan A of course is to recover from backup.
But sometimes backups fail (because they’re not tested), or are forgotten (because they’re not automated). Then we have Plan B: (fill in the <your info> as necessary)
curl -X POST "https://centralusdt<app or pilot><id>.epicorsaas.com/SaaS<id><app or pilot>/api/v2/odata/<companyID>/Erp.BO.ConfiguratorDefSvc/ConfiguratorDefs" -H "accept: application/json" -H "X-API-Key: <your key>" -H "Content-Type: application/json" -d "{ \"Company\": \"<your company>\", \"ConfigID\": \"<your config name>\", \"Kinetic\": false}"
Or pass params through Swagger or Postman or whatever. The “Design in Application Studio” value is an instance of client-managed data integrity and is trivial to update using REST. It’s usually the same story for DMT, but there are no DMT configurator paths.
1 Like
Yes… that is the magic checkbox, and yes, it is a one-way street. once converted, there is no going back. I did request that an additional warning box pop up if someone checks this box on an existing configurator. You also need to be on the latest version of Kinetic to take advantage of all the Kinetic features in the configurator. This was one of the later applications to get converted.
Should we be planning on a full configurator re-write by 2024? which is when classic screens are set to go away? Or do you think the configurator backend will still be available?
I’d also like to know what the roadmap looks like. There’s a strong possibility that if the classic configurator ever goes away, we will never upgrade past that version.
@kylepbsps @KevinK I’m a little late to this thread but I’ll add that I’m hoping for a clear roadmap description at Insights. I’ve talked to a few folks inside Epicor and they’ve indicated that b/c the QA module can use it too, the ‘Configurator’ will not simply go away or be replaced with KBMax, but rather be converted to Kinetic. I’m hoping the tools set is available this spring so we can take a look at it. This does mean a rewrite of sorts, but if the initial conversion (which Tim mentioned above) works well enough, it might just be some UI fine tuning and a little code work. But that depends on your CFG complexity of course.
The one thing I noticed about the Kinetic editor (for the rest of the UI) is that almost everything is available to it. All the rest calls you could possibly make are available in the event editor (or almost all of them). I dare to hope that the CFG editor is the same, and that the CFG can now have the power it should’ve had before to interact with the database and/or other transactions in some way.
4 Likes
Thanks @timshuwy for the clarification of configurator types above. The techref seems to be silent on the matter.
@zwilli526 post makes me nervous about our upcoming migration to Kinetic.
Is the Kinetic Configurator ready to go? Or does it need to bake a bit longer?
I have 2 configurators that did not convert to Application Studio successfully. Is there a way to diagnose what is causing the conversion to fail?
Based on testing and advice (from a source who shall remain nameless), we can’t pursue using the Kinetic configurator / App Studio.
Two issues to date have made this untenable:
- Unsuccessful conversion from classic to Kinetic configurators. We are unable to diagnose why the conversion is unsuccessful, no errors are reported or logged (to my knowledge), we just get a blank screen in App Studio. This means a complete rewrite of the affected configurators (not all bad, but a lot of work).
- Instability of the Configurator in App Studio. We have tried working on configurators that did convert from classic but have encountered unrecoverable errors wherein the entire configurator is lost and must be recovered from backup. This is just too risky for a production solution.
We just want to share our experience and see if anyone has similar experiences.
We’ll continue to test as time allows and are excited by the potential of the App Studio.
We are seeing the same think with our migration to the Kinetic configurator. Conversion completes and the configurator in Kinetic is blank.
Please report this to Tech Support. This should not be happening. There should either be an error reported, or you should have something to work with.