...
Name | Title | Mandatory | Default | Example |
---|---|---|---|---|
PL/SQL statements to be executed | true |
| select sysdate from dual | |
JDBC connection string | true |
| jdbc:oracle:thin:@localhost:1521:XE | |
User name for database access | true |
| schema username | |
Password for database access | true |
| schema password | |
variable_parser_reg_expr | Regular expression to parse dbms_output and set order parameters for next job steps | false | ^SETs+(\\s)\\s*ISs(.*)$ | following line DBMS_OUTPUT.PUT_LINE('SET order_date IS '|| v_order_date); will be parsed by regular expression ^SETs+(\\s)\\s*ISs(.*)$ will result in order parameter order_date="20140915" |
...
command
- The PL/SQL code be
saved to a separate file i.e. get_order.sql , and subsequently sql file can be referred as the value of the job parameter "command", this is a recommended approach to achieve "separation of concern" in application architecture.
Code Block language sql <param name="command" value="config/live/commn/sqls/get_order.sql"/>
PL/SQL code can also be specified as the value of the parameter command, entire PL/CODE can be written as part of the Job.XML, this approach is preferred
Code Block language sql <param name="command" value=" DECLARE v_order_date DATE := SYSDATE; BEGIN SELECT SYSDATE INTO v_order_date FROM DUAL; DBMS_OUTPUT.PUT_LINE(' +++ +++'); DBMS_OUTPUT.PUT_LINE('SET order_date IS '|| v_order_date); DBMS_OUTPUT.PUT_LINE(' +++ +++'); END; "/>
- Before the script is executed, the script will be analyzed by the job.
- Should JobScheduler parameter names be containted in that script then they are substituted by their current value.
- The following notations are supported: %parameter_name%, ${SCHEDULER_PARAM_parameter_name}
db_url
- JITL will need an standard JDBC database connection string i.e. jdbc:oracle:thin:@localhost:1521:XE
db_user
- DB Username to execute PL/SQL code should be executed, this db
db_password
How can results be used in subsequent jobs?
...