I have found no other way to validate master detail hierarchies, than using
validateEntity() function can only prove useful when examining the fields of the current record. There are cases however where you need to verify that the entire tree is correct. Consider for instance a cases where you need to verify that all items included in an order are eligible for seeding to the user's dispatch address. For cases like this you need to examine your data just before committing and the
beforeCommit() does just that.
During before commit you can practically traverse your entire M/D tree using association accessors and verify that everything meets you business rules.
If anything fails to validate then raising a JboException will prevent the actual commit and the exception error message will appear on your
Unless you modify your application module configuration and set the
true, all exceptions thrown inside the afterCommit() method result in a roll-back which completely destroys the data hierarchy just build. As Steve Muench puts it,
When this flag is true, the framework will take an in-memory snapshot of the pending state of the application module, and then use this snapshot to reinstate that same pending state in case any of the beforeCommit() methods fail with an exception. If everything goes successfully with no errors, the in-memory snapshot is not used and will just get garbage collected.
To change the jbo.txn.handleafterpostexc parameter, right click on your application module inside the application navigator, then select
Configurations... from the pop-up menu, click the
Edit button from the resulting dialog box and you are there.