In a method directive on ConfigurationRuntime.ProcessDocumentRules post, LINQ was throwing exceptions and conditions weren’t triggering when I expected. So I disabled that BPM and replaced it with one that does nothing except dump the datasets to JSON. I found that the contents of configSequenceDS and configRuntimeDS are radically different from what appears in the trace logs. Why would this be? Am I supposed to do something to make them load properly?
In configSequenceDS, there’s an extra, partly uninitialized PcStruct for every one that appears in the log. And in configRuntimeDS, none of the PcConfigurationParams from the log are actually there. Instead of three records for StructIDs 0/1/2, there are two identical, mostly uninitialized ones for StructID 0.
Another weird thing about this particular method is that the initialized PcStruct always have RowMod “U”, even in post.
Have you ever run into another method that behaves like this?
I’ve always assumed that what I see in parameters in the trace log is what BPMs should see in pre, and what I see in returnValues is what BPMs should see in post. Until now, I’ve never had reason to doubt that.
Edited my previous comment, as I don’t usually work with traces I didn’t catch what you meant by parameters/returnValues.
I’ll try and take a look later but I would expect the same, parameters is what is sent to the method so a directive which runs before should get them as they are, and also if the returnValues is dumping the contents of the same datasets after the method is run it also makes sense that the post bpm would see the same.
Unfortunately I am not familiar with the configurator, so I can’t test the same scenario as you, I will find some internal resources and see if I can test the same method as you. If you can give me a simplified list of steps I could check a bit faster.
If you create a product configurator, ProcessDocumentRules should be called even if you don’t have any document rules. My test part is a configurable assembly with one configurable subassembly (pull as assembly) and one configurable material (plan as assembly), so I expect three PcStructs and three PcConfigurationParams. Everything looks correct in the trace log. But in the BPM, there are six PcStructs (two for each struct ID) and only two PcConfigurationParams (both for struct 0.)
I made few tests dumping the sets at these 3 points:
At the end of ProcessDocumentRules
Inside the Post Process Method Directive
Inside the Client Adapter right after the call to ProcessDocumentRules
What you are seeing in the BPM is exactly the same as the TableSets are at the end of the ProcessDocumentRules.
The trace dataset is exactly the same as the client DataSets are after the call to ProcessDocumentRules.
So the differences you are seeing is probably the logic that converts between client datasets and server tablesets. For example, if you mark a record with RowMod D on the server, on the client this record will be deleted from the client dataset so it does not appear on the UI.
Hmm. In the BPM, the actual type of configSequenceDS is a Erp.Tablesets.ConfigurationSequenceTableset. And the trace log represents it as <returnParameter name="configSequenceDS" type="Erp.Tablesets.ConfigurationSequenceTableset">. So it doesn’t appear to have been converted.
Even if the type were different, the main issue is not the data model, but the entities it’s representing. I’ve noticed things like duplicate identical OrderHeds in post BPMs on SalesOrder methods, but I’ve never run into these kinds of major differences between the BPM and the trace log. Fortunately, the fields I need from PcConfigParams are among the few that are populated.