ABAP_to_the_Future

Using BOPF to Write a DYNPRO-Style Program 8.2
Coding the Validation
The process of coding the validation is exactly the same as when you created a
determination in Section 8.2.5. A custom class has been generated for you; this
time, it implements the /BOBF/IF_FRW_VALIDATION interface. If you look at the
class in SE24, you will see that it has the exact same methods as the generated
determination class: CHECK_DELTA, CHECK, and EXECUTE.
The first two methods are the same as before. To review:
왘 CHECK_DELTA
This optional method reads the entire object structure to see what has changed
since the last time it looked (the last validation) and removes any nodes (from
being checked) in which nothing of any interest has changed.
왘 CHECK
This optional method can look at the current values of any field in the business
object and remove any nodes in which one of the fields has a value that means
that the validation would serve no purpose.
Those two methods are 100% identical to the ones in the determination, which
was discussed at length in Section 8.2.5 and won’t be reiterated here.
The EXECUTE method in the validation is the one that does the actual validation
work, but it’s different from the EXECUTE method in the determination in that the
error handling in a validation needs to be a lot more complicated than that used
in a determination.
In a short while, you’ll see that the BO PF needs a very specific type of message
object. However, the monster model does not need to know that, so define your
own monster specific exception class in which you will send out details of what
went wrong (Figure 8.18).
Figure 8.18 Monster Exception Class
321