PLP register field not displaying values

[photon]

We have two 8.2 environments with PLP SV 101. In one environment, all of the parameters for the register field lists display as expected. In the other, the same fields are blank. However, we know there is indeed a value there as the plan calculates correctly and we can see the resulting entities in the export to the cube.

For troubleshooting purposes, we’ve been using the entity field (aliased as Department in our solution.)

The Register Field List setup is entirely conventional:

The parameter is configured the same in both environments:

The function in the business rule that it’s calling is the same in both environments. I’ve tested the resulting SQL in SSMS and it returns valid values. I temporarily added some logging to make sure the method was actually hiring and returning a data table as expected; it is. The fact that it does populate the entities when calculating the plan data suggests all of this is fine and it’s just a display bug but nothing I can find seems to allow it to display properly.

What can we do to address this?

I know the parameter is custom but the issue doesn’t appear to be with the parameter as it works fine in every other environment we have except this one. What we need help explaining specifically is the display issue, which seems like a bug.

[MikeG]

Hi @photon check to make sure you do not have a Control List applied to the Entity column on the Register Field List.  The rule also uses WFEntity, in that register are there assigned Entities at that Base Input Profile?  It's either the assigned Entities or the Bound Parameter / Control List.

Hope this helps,

[photon]

There doesn't appear to be a way to apply a control list to Entity and there are entities assigned because it does have values, we just... can't see them.

I opened up the rule, pulled the SQL out of the method, and ran it to verify that it's getting all the expected records. We can even run the plan calc with the "blank" entity column and all the calced data has all the correct entities, it's only on the register/data entry screen that they can't be seen.

[MikeG]

Try restoring back to the original PLP default Entity parameter: MemberListEntity_PLP.  Note the Display and Value members noted here.

If that works, work backwards to get your Entity list sorted which looks like the issue you want to solve.  Otherwise the Entity list is metadata order.  Hope this helps.

[photon]

Well, reverting it to the default parameter does work. Curious.

We have five total environments. The two 8.2 environments are recent copies of Prod. One has this behavior and one does not. I even tried exporting the "good" parameter from the environment where it works to the environment where it displays weird and it didn't change the behavior. It would seem that it's not the parameter and is instead something to do with PLP itself.

[MikeG]

Hi @photon you're lucky you have a client on v8.  I'm way behind, my 2 main clients are still on v7.2.  How about making a copy of that function in PLP_SolutionHelper, GetWorkflowProfileEntityList, and just sort the table alphabetically before returning it?  Retain the original, just add the sort code before the Return statement.

[photon]

I am the client! XD

We only have one substantial maintenance window a year and we need some features in OFC SV3 which requires PV8. Plus, the .Net framework necessary for 8.1 is EOL in just a few months so it's 8.2 or nothing. The relatively short support windows from MS for the .Net frameworks may become a problem in the long run but that's a different topic.

Both of the 8.2 environments are clones of the same Prod environment and we specifically avoided any code/config changes to PLP. I can't fathom what would cause such an unusual display issue. I deleted the parameter and recreated it. I tried importing it from the environment where it works. The manner that the name/value datatable is built is wildly different for each parameter (the default parameter uses the API and a long function, our custom function runs a short bit of SQL) but ultimately they're both returning a valid datatable with the correct name (per their parameter settings) with valid column names and valid values.

There doesn't appear to be any valid way to explain the differences between the display of the two.

[DanielWillis]

Definitely sounds very weird. Ignoring the fact that its working in one and focusing on the fact that it isn't working somewhere.. Could it be something like the Results Table Name? Hard to see in the screenshots but I think you have yours as WFEntityList and the original one is ListItems. Perhaps its hardcoded somewhere. I'm just going along the lines of trying to get it back to as close to the original working version.

[photon]

Each parameter is set to use the same results table name as the datatable name in their respective function.

[DanielWillis]

Parameter in the same workspace as PLP? This caught me out yesterday

[photon]

Ooh, that is a good thought but we only have the Default workspace (so far)

If it were entirely broken, I would expect it to fail but this is curious because it displays nothing for Name but still has a Value behind the scenes. Luckily, our PLP managers have decided it's not worth delaying the platform upgrade over (since reverting it to the old parameter is fairly close to the custom behavior) but I have a feeling they're only going to tolerate it for so long.

[DanielWillis]

It doesn't really fail if there is an issue with the parameter from what I've seen. You just get the blank field. Same as when the value stored isn't in the drop down list options

[photon · Accepted solution]

So, there was a bit of red herring with the working environment as it, too, broke after we refreshed data in the register.

As it turns out, this is bug PF6-5346. Support is able to provide some code and a workaround (though I haven't implemented it yet.)