Kinetic Configurator - Compile errors with await statements between App Studio and Configurator Rules

Kinetic ERP
1

On a brand new, cloud based, Kinetic Configurator, I had gotten my inputs design far enough along that I decided it was time to build my Method of Manufacture and layer some Configurator Rules on. Getting them to play well with each other seems to be where I’m stuck.

There is a bit of PCLookup action happening in my inputs, especially in the On Field Changed action. These all work fine within the Application Studio preview of the configurator, but each PCLookup required the use of an await operator to get it to pass the syntax check as in:

Inputs.TextBoxSheetDesc.Value = await PCLookUp.DataLookup(lookupTable, columnName,rowName);

But… as soon as I go into Configurator Rules and try to add any kind of rule on an operation or material I get compile errors telling me that I can’t use await operators without an async modifier.

The 'await' operator can only be used within an async method. Consider marking this method with the 'async' modifier and changing its return type to 'Task'.

So I appear to be required to use the await operator in Application Studio, but forbidden from using it in the Configurator Rules.

Converting my loookup logic to a server side UD Method does not solve my problem. I can get around needing to use the await operator in the UD Method, but I’m required to use await when calling the UD method. It seems I’m also not allowed to skip the PCLookup functions and go straight to Db.PcLookupTblValues in the On Field Change action like I did in the UD Method.

I fell like I have to be missing something here. Anyone have any insights into this?

2

I dont think the Kinetic Configurator is quite there yet, I have suffered lots of issues in the app studio, where it shows an error, when I try and call a UD method, but only sometimes.

The error has no detail, is just helpfully says Error.

3

Normally you want everything to be async “all the way up”, as they say. But if you’re forced to call an async method from a non-async method, you can use GetAwaiter().GetResult():

Inputs.TextBoxSheetDesc.Value = PCLookUp.DataLookup(lookupTable, columnName,rowName).GetAwaiter().GetResult();

I would hope there’s a checkbox somewhere that says “call this rule asynchronously” so you wouldn’t need to do this.

4

Have you tried switching to a BAQ look up?

I have a 2021 classic configurator that we will be switching to Kinetic soon. It uses BAQs for combo box Dynamic List values, instead of the PCLookUp.

If this works in Kinetic, might be a solution for you, and keep mine working after the switch.

5

I did give this a quick try and it did pass the syntax check, but when I preview it, it doesn’t work. There are no errors, but the logic no longer functions.

I did try a quick version in classic mode and everything works fine (but slightly differently).

6

I’ll try out the BAQ approach and see if it behaves any better. I’d really like to try to keep this all in Kinetic if I can.

7

This is a little embarrassing… I think this may have all been cause by user error.

Don’t mix and match Classic and Kinetic forms. This was at least half of my problem. The Configurator Designer defaults to Application Studio, but the Configurator Rules defaults to Classic. Turns out, this fails pretty much no matter what.

My old one still doesn’t work, but I did create a new Configurator and as long as I launch the Configurator Designer and the Configurator Rules both in the Kinetic version it does seem to work. Maybe I corrupted something with the mix and match of them.

1 Like
8

That sort of fits the patterns of other configurator types. You can’t run more than one kind of configurator (like a Product Configurator and a No-Inputs Configurator) on subassemblies within the same configuration session. Subassemblies that have the same type of configurator as the base part will run, and the others just won’t, with no error message unless their failure to run breaks a configurator that does run.