runPLSQLScript

Executes an Oracle PL/SQL script. This operation takes the SQL script as an input and processes each statement in the database using JDBC.

This operation was deprecated in release 4.0.3.10, and will be removed in a future release. All functionality is merged into the runScript operation. Please use that operation instead in your workflows. Run Destructive is new property and it defaults to false, so if you are running delete, truncate, drop statements then make sure to check this input on plugin operation on your workflow.

Please note that each statement in the SQL files must be delimited by a forward slash (/) on its own line. Also this operation supports intermixed regular SQL statements (non PL/SQL statements), however, these statements must not end with a semi-colon. See the Appendix for sample PL/SQL script file:

  

Environment/Instance Properties

Property Name

Property Code

Required

Description

JDBC URL

FDJDBC_URL

Yes

The JDBC URL of the database.

JDBC User

FDJDBC_USER

No

The username that will be used to connect with.

JDBC Password

FDJDBC_PASSWORD

No

The password of the username.

JDBC Driver Path

FDJDBC_DRIVER_PATH

Yes

Classpath for locating the JDBC Driver (e.g. for Weblogic - {ORACLE_HOME}/oracle_common/modules/oracle.jdbc_11.2.0/ojdbc6.jar).

  

Project Properties

Property Name

Property Code

Required

Description





  

Inputs

Input Name

Input Code

Required

Description

User

FDJDBC_INP_USER

No

The username that will be used to connect with. This input takes precedence over the environment instance scoped FDJDBC_USER property. This input is required if the FDJDBC_USER property is not specified.

Password

FDJDBC_INP_PASSWORD

No

The password for FDJDBC_INP_USER. This input takes precedence over the environment instance scoped FDJDBC_PASSWORD property. This input is required if the FDJDBC_PASSWORD property is not specified.

Script File

FDJDBC_INP_FILE_NAME

Yes

The path to the script to execute. If a relative path is given, the path will be assumed to be in the FD_ARTIFACTS_DIR.

Run Destructive

FDJDBC_INP_RUN_DESTRUCTIVE

No

This option allows destructive statements to be run. See Special Considerations below.

  

Outputs

Output Name

Required

Description




  

Artifacts

This operation consumes one or more SQL files, and an optional sequence file, from the artifacts repository.

  

Endpoint Selection

This operation will select all available endpoints associated to the environment/instance.

  

Endpoint Execution

This operation will randomly execute on one of the endpoint identified during selection.

   

Special Considerations

The statements in the SQL files must be delimited properly.

The FDJDBC_RUN_DESTRUCTIVE input allows a mechanism for disallowing certain destructive SQL commands. If the input is set to true: DROP, DELETE, and TRUNCATE will be allowed within the script. If the input is set to false: the plugin operation will abort with a validation error prior to running any of the commands in the script. This check cannot stop malicious actors, but instead helps to provide some security against accidental running of destructive commands. It is up to the customer to decide whether they want to allow such commands.

Sequence File for multi-file processing:

If you want to execute multiple SQL scripts, instead of specifying an SQL file within the FDJDBC_INP_FILE_NAME input, a file containing an ordered list of SQL files to execute may be used. The plugin will detect whether a SQL file or a sequence file has been specified based on the format of the file. The format of a sequence file is as follows:

!SEQ
CreateHR.sql
GrantHR.sql
ADFStateMgt.sql

The !SEQ line (must be the first line) at the top of the file indicates a sequence file. After the sequence line, an ordered list of files to run follows.

  

Replacement Properties

The SQL files are pre-processed by the plugin to transform any defined replacement properties.  An example usage of replacement properties is when the schema name cannot be hard-coded because it varies from environment to environment.

  

Alternative to Property Replacement

As an alternative to property replacement for dynamic schema injection, consider the use of an ALTER SESSION command to modify the schema user which will run the statements.  With this approach you need to ensure that the statements are not schema qualified. 

For example
ALTER SESSION SET current_schema=${{MYINST:MYSCHEMA}} 

Where MYSCHEMA is an environment instance property for the MYINST instance.  To achieve this you would create an environment instance-scoped property on the workflow and associate the workflow to the MYINST instance.  You will then be able to provide values for each environment associated to that instance.

  

Sample SQL script file

CREATE OR REPLACE PACKAGE emp_mgmt AS
   FUNCTION hire (last_name VARCHAR2, job_id VARCHAR2, 
      manager_id NUMBER, salary NUMBER, 
      commission_pct NUMBER, department_id NUMBER) 
      RETURN NUMBER; 
   FUNCTION create_dept(department_id NUMBER, location_id NUMBER) 
      RETURN NUMBER; 
   PROCEDURE remove_emp(employee_id NUMBER); 
   PROCEDURE remove_dept(department_id NUMBER); 
   PROCEDURE increase_sal(employee_id NUMBER, salary_incr NUMBER); 
   PROCEDURE increase_comm(employee_id NUMBER, comm_incr NUMBER); 
   no_comm EXCEPTION; 
   no_sal EXCEPTION; 
END emp_mgmt;
/
grant execute on emp_mgmt to HR;

grant execute on dept_mgmt to HR;

The following macros are not currently supported in the footer:
  • style