So for about 6 months on and off I have been plugging away at converting our classic configurators to Kinetic. Some basic configurators to calculate price convert easily(by easily I mean it creates the Kinetic UI and I can spend my time fixing the UI). Some of the configurators that create the MOM I have to correct the UDMethods. to not use ref or out modifiers for parameters (The pleasure this is we should all strive to avoid ). This brings me to the heartburn I have been suffering. I have one, maybe more, that I go through all this trouble and still doesn’t convert. Does anyone have any suggestions or hints as to how to get these to convert? My thought is to comment out the exported XML piece by piece and see what allows it to convert then rebuild that portion. This is going to be time consuming and tedious so I am hoping someone here has an awesome solution for me. Thank you in advance.
@MattSpotts, I’m interested as well. I was not able to convert any of our more complex configurators so I gave up. I started writing new configurators in Kinetic but quickly gave up because they would corrupt and become unusable. We’re still using Classic to run the configurators.
We recently updated to 2023.1.5 and I’m trying to decide if I hate myself enough to try again.
Once there is a hard date for Classic end of life, we will hopefully have 1-2yr advance notice, then we are tackling the same issue.
Well I have some answers. Sit back grab a cup of coffee and don’t kill the messenger
To get them to convert:
- Please for the love of all things holy do not use your original configurator. Copy to a new one.
- All user methods that have parameters have to have the modifiers removed. This means that if you have an out parameter you will have to rewrite the code that uses it to call more methods to make it work.
- Export it then try to convert it.
- if it works then great. if not move on to 5
- delete configurator.
- recreate configurator uncheck use application studio
- import the export from 3
- Comment out all code in the methods, document rules, on Load, on loaded, on complete, on save.
- export again
- convert once more.
This should have converted. Now go through and uncomment the code and find which ones fail and correct the code. I am currently on one that the method is a decimal and simply declaring and initializing the decimal then returning it still tells me not all code paths return a vaule
As far as the corrupt configurators. This one is definitely fun.
Check often if it is corrupt close out come back in. if it’s corrupt.
- export
2.Extract the xml file from the zip the export created - Create a new configurator with the use app studio unchecked
- import the xml you extracted in 2
- check the use app studio check box
- verify it opens
- export
- import over the original one that was corrupt.
Whew. That’s the roller coaster I am on. We are getting ready to update to 2023.1.5 in live which means I have my test environments. The above steps works in 2023.1.5. I am trying hard to get these uplifted because this is what is stopping us from going live with Kinetic in the Browser. On the upside I think I now qualify as being in the Import/Export business
@MattSpotts, thanks very much for that.
I think I quit at step 6 of the first block.
I’ll definitely try the corrupt fix you suggest.
when you converted, did you have to convert the Rules at all? or just the configurator from the designer.
The configurator from the designer. Although there is alot that doesn’t convert so I am working with dev to get me the errors a little faster
One issue we are hitting is how do you handle the cutover from Classic Configurators to Kinetic Configurators when it comes to existing lines on a Quote/Order. If they are using the Classic config, do they have to delete and readd? Or can they just change the PartRev to use the new Kinetic Config?
You should be able to just change the PartRev. If the new rev has an approved Configurator, you’ll be able to configure the new rev with the correct configurator. You will have to configure it, though.
We’re working on this now and have not fully tested it, but I agree with @kve. In addition, IF you leave the previous revision active AND you have the full client and Edge Agent installed - when you open a quote line with the previous revision it should open the classic Configurator screen.
Our plan, however painful, is that once we go live with Kientic Configurator, all ‘classic’ revision quote lines will need to be reconfigured if changes need to be made otherwise those quote details will move to the SO and Job without issue.
Yes as @MikeGross said, you don’t necessarily need to reconfigure with the Kinetic Configurator Rev unless changes need to be made. If they’re already configured and ready to become an Order / Job, you can leave them alone as long as the revision is active.
What we did was check the design in Appstudio check box and then import our working kinetic configurators. To get to that point I had several environments.
- completely untouched and no one can change the configurators.
- development environment where I made a copy of each configurator and worked to convert it using the less than stellar conversion. Work through all the issues etc. I never touched the originals because I could delete the duplicate and start again. Never touch the design in appstudio checkbox on the originals.
- A user testing environment.
- Live
Users would compare classic in environment 1 to Kinetic in environment 3
Day of Go live we moved the configurators the night before and told the users to use as much as possible and we internally gave until 10am to decide go with a backup or push forward. Luckily we pushed forward and all was good. There were issues but some were just the new layout, some were from the changes we made, others were old problems no one noticed.
Hope this helps.