REST and the Configurator

I’ve been reading every old post on here I can find about creating configured parts via REST. Just wondering - am I flogging a dead horse here? Has anyone been successful in their attempts to import PC input data and trigger the method rules that build their BoM/MoM?
I see a few older posts about exploring Functions to do the grunt work with Product Configurator. Is this a more viable approach?

Keen to see what approach others have taken - I know I can’t be alone in trying to achieve this!



I am doing this right now, pushing configuration from a web application directly into PcValueSet… It’s not easy, there are pitfalls, definitely not supported, and may or may not work depending on how you use your configurator (specifically, if you only ever reference your inputs’ .Value property, and not Description, or others…). With all that said, it’s not impossible… I have 7 configurator sequences all working using this method at the moment.

1- First, get a template of the XML configuration from PcValueSet for each page of your configurator, and replace every value with a placeholder tag, to be filled in later. Also get a template of the input properties XML, you can just use it as is, provided you don’t use any of the properties enumerated in there. If you do, or if you really want to do it 100%, you need to also put in placeholders in there to be populated…
2- Check the approved status of the configurator from PcStatus and get its ConfigVersion
3- Get the next configuration sequence number from the SysSequence table, it’s the “PcValueGrpSeq” CurrentValue, to which you add the Increment, and update SysSequence.CurrentValue, which is your GroupSeq for your new configuration.
4- Create the PcValueGrp entry, using your GroupSeq value.
5- Create a PcValueHead entry for each configurator in the sequence. You can get the RuleTag value from the PcStruct table.
6- Fill in the XML template(s) from earlier and create one PcValueSet entry for each page.
7- Once everything is saved, update the QuoteDtl.GroupSeq value, along with LastConfigDate, LastConfigTime, and LastConfigUserID.

Be prepared to have to debug this thoroughly by comparing XML outputs a lot. You should also wrap all of that into a transaction that can be rolled back if anything goes wrong. You don’t want to leave partial configs in the database, or orphaned records, etc…

Also, I have found one quirk, which is that when I call OnChangeofEngineered on the configured detail line, if I don’t set the GroupSeq to 0 before, and restore it after, through direct DB update, when I then call Update it deletes the config. The service is expecting some context flags, but I wasn’t able to find how to set them properly, so I cheated by setting GroupSeq to 0 before update. This is the decompiled condition in question, from the QuoteDtl write trigger:

if (QuoteDtl.GroupSeq > 0 
    && !string.IsNullOrEmpty(OldQuoteDtl.RevisionNum) 
    && !QuoteDtl.RevisionNum.KeyEquals(OldQuoteDtl.RevisionNum) 
    && !ErpCallContext.ContainsKey("ConfigurationRuntime-UpdateQuote") 
    && !ErpCallContext.ContainsKey("ConfigRuntime-ExecuteRules") 
    && !ErpCallContext.ContainsKey("ConfigChangePartNum"))

This is just to give you an idea of what you’ll have to do to make this work… It DOES work nicely, all the way through MRP processing, but it’s a large piece of code to create, and I would only consider this if you are already very comfortable with Epicor data structures, and you really absolutely need to do it. It was a fun challenge for me, but I realize now it could have been a complete nightmare if the configurators had been built differently.


Thanks for such a detailed run-through of how you’re tackling this task. I knew I couldn’t be alone in trying to achieve this.

Just a quick look at your code - where are you calling this from? Are you using REST?

Are you writing directly to the DBs or am I misreading the scope of your setup?



I am writing directly to the DB, in my case from the service backing a web application. In your case, you could put that code in an Epicor Function, and call it from REST.

AFAIK there is no other simple way to do this. There is a SavePCConfiguration method in one of the BOs, but it’s unwieldy and requires ALL the information from each input. If you think you can manage it, then that would be the preferred option. Just run a trace while saving a configuration, the method will be in there to analyze and use. After I spent a few hours trying to figure it out I abandoned that avenue…

You both are very courageous trying this out (@HLalumiere , @RJM )…

@jdewitt6029 @skhan @slitzau


Yeah that comment got my heart racing.

The thing is that @HLalumiere must know a lot about the table structure for the pc invals to be able to do this.

I would much prefer an API with documentation, but that is yet to come.

Maybe I should have put that in bold… :smiley:

1 Like

I wouldn’t even recommend it, but I get it.

1 Like

Yeah, I hear you! I certainly don’t have the knowledge (or comfort!) of writing direct to the DB. Nor would my company allow it. Hence my attempts to find a way of achieving this through REST / functions.

We have a handful of configurators and most are “small”, though I’m sure others might disagree. Our main configurator though has a minimum of three pages plus hidden pages and, depending on which options are selected, over 100 inputs. It’s not uncommon for us to enter over 500 of this product per week, hence my desire to automate this process!

We currently receive orders from wholesalers via email or our own sales staff measure and quote, returning orders on paper which are then entered into the system (how old-school!). It’s too slow to enter these onsite and internet connectivity can’t always be guaranteed.

My current thinking is to tweak our configurator a little so I can load orders into it. I envisage it working like this:

  1. Email orders / internal orders are converted into a “specifications file”. Simple text parsing, this is not a problem and I do it for several of our CAD-driven products to automate CAD drawing.

  2. Spec files would be stored in a repository where a scheduled task would pick them up and write them to a UD table via REST. Again, done this sort of thing before, not a big problem.

  3. The tweak to our configurator adds an additional page at the start of the configurator that would scan the UD table based on customer and PO number. If a spec file exists, auto-load details and hide pages/inputs and mark UD table entry as processed. If not, begin usual data-entry routines.

All of this is doable but I’d love to take this one step further and, for step 3, scan the UD table periodically via a scheduled task/function. If unprocessed entries exist, use REST to create the Order/Line (I can do this bit) and auto-convert the UD entry into a configured order. This last bit is where I’m stuck.

I think the approach you describe is much more sensible if you just need automation. In my case the web app is a responsive mobile website for the reps on the road to enter and manage quotes in, with lots of extra validations, live over 4G using a tablet.

In your case, I think you could get away with just modifying your configurator to always get the input values from the UD table on page load. You will need to create server UD methods to get the data from the UD table and populate your inputs on page load. This way, all you need to do to launch your automation is click the configure button, go through the pages which will autofill, and save.

If you’re crafty you can probably even figure out a way to automate that part in the background. Check the tracelog of when you click Configure and the configurator opens, and when you change pages.

1 Like

I like Hugo’s idea of sourcing the information from a UD table.

1 Like

We’re facing the same problem, attempting to migrate a 3rd-party configurator from Epicor 9 to Kinetic. The configurator writes to the PcInValue table in E9. Are there REST APIs or BOs in Kinetic that will allow us to use the PcValueSet/Grp/Hed PC tables? Or is the only option to write to the tables directly?


Hi Brian, welcome to the forum.

My understanding is that PCInValue is now redundant. We’re still on E10, currently making the move to Kinetic. I’ve been able to automate our configurator in E10 using REST though. The data that was once stored in PcInValue now resides in PcValueSet, though it’s stored in XML format.

I’d advise against writing directly to the tables, and there really is no need. The REST calls will handle this for you. If you haven’t already, run a trace as you manually use your configurator. All of the BOs and Methods are spelled out there for you. It’s tedious but go through all of the changes made by the BOs and replicate with your code. If you need further help, start a new thread and tag me. I’ll see if I can point you in the right direction.

Good luck!

1 Like

Thanks Ryan. Do you know where can I find more information about the REST calls that are specific to the Kinetic Part Configurator? We’re still going through the upgrade process to Kinetic and don’t have a lot of experience with the REST APIs yet.

Hi Brian,

Your best bet is to run the trace logs as you use the Configurator manually. This will give you a full list of each BO and Method you need to replicate with your code. Make sure you catch full datasets so you can see what information is passed into each method and what is data is returned.