ExecuteProgramRun: Failed to create output table: BatchOutPRxxx
code was imported from Development to test and worked ok (propositions, decision-data, strategies, segments) a new campaign definition was created locally.
when it was imported to pre-production, the new Campaign run fails with the error message "Failed to create output table: BatchOutPRxxx".
looking at the Database we can see that the BatchOut table is indeed created, and all 5 indexes are created on it properly, and the App Explorer we can see that the BatchOut class was created properly, as is the DataSet, but not the report Definition.
we traced the Activities for the Campaign run, ExecuteProgramRun CreateBatchOutputConfig pzCreateBatchDecisionOutput pzCreateBatchTable, and compared a successful campaign with our failed campaign run ... all steps appear to be the same, other than for our failed case, when it returns from CreateBatchOutputConfig at step 11 of the ExecuteProgramRun Activity, StepStatusFail has been set so it jumps to step 40 and the run fails with the error message.
I would have guessed that something was not moved properly, but the same product package was imported to the lower Test environment and it ran fine.
also, since other Campaigns run successfully in the pre-production environment, the problem does not appear to be environmental.
this was an interesting problem, by process of elimination we determined the offending property, which was defined on the base SR class and was available to us, but in a ruleset higher up the ruleset stack ...
by making a copy of the property in a lower ruleset, it was then seen properly by the Batchout class.
so it is an inheritance/scoping issue during rule resolution. Although it is not obvious why one set of propositions make reference to this property, while others do not. the property in question is not used or directly referenced for the proposition in question, it is just inherited from the base SR class, and for some reason has been made a requirement in the generated Batchout.
at least we now have a work-around. But we would have resolved this much quicker if Pega did not hide the Error in the first place, and only exposed it when DEBUG is turned on.