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.
Accepted Solution
Ford Motor Company
CA
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.
Ford Motor Company
CA
Further investigation shows that it fails in pzCreateBatchResultsReport step 15 the Obj-Save
the Activity creates the Rule-Obj-Report-Definition, populates it, and on the Obj-Save while an error occurs, it is not displayed as an error, and only shows up with DEBUG logging ...
DEBUG - obj-save failed due to an invalid page.
com.pega.pegarules.pub.database.BadInputException: Trying to save an invalid page:
Trying to save an invalid page: page is not valid
.pyUI.pyBody.pyUIFields(213).pyFieldName:
This is not a valid property, or this is a property that cannot be used here.
so the error is not displayed and it just floats up the tree until it is handled and displays a totally misleading error message.
now to understand why this property is used in our case, and not others.
Accepted Solution
Ford Motor Company
CA
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.