How to design easy to read input validation in PL/SQL? - oracle

Question

I am working on a total rewrite of a PL/SQL program which is an EBS inbound interface to a third party system. In this process we receive input from the 3rd party system which is loaded into a table, and the program loops through the table to call EBS APIs for modifying and creating records. The business logic is very complicated and the code has spiraled out of control which is the reason for the rewrite.
Before calling some of the EBS APIs, we need to validate the incoming data against what is in the Oracle EBS system. The current code has several (20+) procedures to check various pieces of incoming data. Each of these procedures returns a status and a message. Then there is one main procedure which calls all of these validation procedures, and after each procedure call it looks at the status and message - the main procedure is basically a sea of if-else statements and it is extremely cumbersome to follow.
I'm wondering if there's a more suitable practice for performing this quantity of validations so that the code is easier to read and maintain. I have considered making all of the procedures into functions that return boolean values but then I still have the problem of tons of if-else statements in the main calling procedure. I'm just looking for other ideas at this point, the ultimate goal is to improve maintainability of this program.
Thanks in advance

Answer 1

You can't escape the fact that if you have 20 things you have to evaluate you need to have 20 check points in a one way or another.
Your problem statement is very broad but below is one example how I have implemented the same pattern succesfully. The main idea is that the checks (or validation) do not pollute that main business logic but are clearly separated so the main business logic is easy to follow. PL/SQL is sometimes a bit verbose language - here the verbosity goes into exception handling.
Note that in the example I have made some assumptions that might not hold in you specific case.
Validation package:
--
-- NOTE: PL/SQL look alike pseudo code - won't compile
--
-- br = business rule
create or replace package body so46_br is
-- different exceptions required only if each case needs to be identified
-- later in exception handling
err_br_1 constant pls_integer := -20001;
ex_br_1 exception;
pragma exception_init(ex_br_1, -20001);
-- ...
err_br_20 constant pls_integer := -20020;
ex_br_20 exception;
pragma exception_init(ex_br_1, -20020);
procedure assert_br_1(/* input params */) is
v_fail boolean := false;
v_msg varchar2(2000);
begin
-- validate the business rule #1
if v_fail then
v_msg := 'Construct detailed reason why the validation failed.';
raise_application_error(err_br_1, v_msg, true);
end if;
end;
-- ...
procedure assert_br_20(/* input params */) is
v_fail boolean := false;
v_msg varchar2(2000);
begin
-- validate the business rule #20
if v_fail then
v_msg := 'Construct detailed reason why the validation failed.';
raise_application_error(err_br_20, v_msg, true);
end if;
end;
end;
Business logic package:
--
-- NOTE: PL/SQL look alike pseudo code - won't compile
--
-- bl = business logic
create or replace package body so46_bl is
procedure main(/* input params */) is
begin
-- #1 validate input params/business rules
-- assumes we can quit if any validation fails
so46_br.assert_br_1(/* input params */);
-- ...
so46_br.assert_br_20(/* input params */);
-- #2 do the other business logic things
exception
-- assumes each validation failure needs to be identifiable
when so46_br.ex_br_1 then
so46_log.log_br_1(dbms_utility.format_error_stack ||
dbms_utility.format_error_backtrace);
raise;
-- ...
when so46_br.ex_br_20 then
so46_log.log_br_20(dbms_utility.format_error_stack ||
dbms_utility.format_error_backtrace);
raise;
end;
end;