Stored procedures
If you are using Rational® Integration Tester 8.0.1 or later, you can record and virtualize most stored procedures.
Rational® Integration Tester 8.6.0.3 and later versions also support the virtualization of packaged procedures in Oracle.
With many applications, information persisted within a database is accessed directly through tables and views, and it is also accessed and modified through stored procedures. As with any service, the logic embedded within the stored procedure might not yet be available, or it might be slow to run, or it might even have costly side effects when the procedure runs.
Because of these differing behaviors, record stored procedure executions to observe the interactions and then construct stubs to mimic existing behavior or introduce new or even erroneous interactions.
One of the ways that a database stub can do that is to reply parrot-fashion, that is, repeating without understanding, to the stored procedure calls made by any application that is interacting with the physical database. For more sophisticated responses, Rational® Integration Tester can also match against input parameters to determine which results should be provided. Further, it is possible to modify the signatures of stored procedures or introduce entirely new ones to aid development or integration testing.
While learning a stored procedure that returns a result set to the application, Rational® Integration Tester learns the result set one row at a time.
Oracle databases
Oracle databases call
stored procedures by using a JDBC escape sequence or by using Oracle
PL/SQL block syntax. Rational®
Integration Tester supports both of these methods,
but does not support full PL/SQL grammar in the JDBC parameter or
SQL statements within the "begin...end"
block.
Rational® Integration Tester uses the block syntax to call the stored procedure only. The
following Oracle PL/SQL block syntax is supported:
// Oracle PL/SQL block syntax
CallableStatement cs3 = conn.prepareCall("begin proc (?,?);end;");