Stored procedure smart service

Data Source Name Input:  This should match what is listed in your admin console as the connection name, such as "jdbc/databaseName" or "java:comp/env/jdbc/databaseName".

Procedure Name Input:  This is exactly that, such as "dbo.myStoredProcedure"

Pause On Error:  True if you want the process to halt during an error, False if you want the process to continue regardless of an error.  This is actually one of my favorite parameters only available in the SP node and Query DB (that I am aware of).  Allows for error handling (errors logged through Data Outputs).  I typically use this as False (especially on external databases we cannot control), then have all error'd notes wait at a Receive Message event, so once the DB is back online, I can restart all at once via an admin process with one click.

Run Validation:  True here will run extra validation to check if the procedure inputs match for the type expected.  There is a decent performance cost associated with this.  Unless the procedure has potential to change, I haven't seen a reason to use True here as long as you match your input types to what the procedure expects (typically easily ironed out in testing).  Also to note, this input is unfortunately not available in the function version, fn!executeStoredProcedure.  That will always run validation, which is disappointing due to the performance hit.  We've had to change to call a web service that calls our validation procedure when we need to validate, say a grid of 1 to 100 lines, via procedure, due to the performance.

Inputs/Outputs:  Any procedure input or output parameters are configured as separate Node Inputs, with the name matching exactly as defined in the procedure.  Inputs only need a Value setting, outputs only need Save Into.

If you have any specific errors or questions, let us know in the thread.  

Data Source Name Input:  This should match what is listed in your admin console as the connection name, such as "jdbc/databaseName" or "java:comp/env/jdbc/databaseName".

Procedure Name Input:  This is exactly that, such as "dbo.myStoredProcedure"

Pause On Error:  True if you want the process to halt during an error, False if you want the process to continue regardless of an error.  This is actually one of my favorite parameters only available in the SP node and Query DB (that I am aware of).  Allows for error handling (errors logged through Data Outputs).  I typically use this as False (especially on external databases we cannot control), then have all error'd notes wait at a Receive Message event, so once the DB is back online, I can restart all at once via an admin process with one click.

Run Validation:  True here will run extra validation to check if the procedure inputs match for the type expected.  There is a decent performance cost associated with this.  Unless the procedure has potential to change, I haven't seen a reason to use True here as long as you match your input types to what the procedure expects (typically easily ironed out in testing).  Also to note, this input is unfortunately not available in the function version, fn!executeStoredProcedure.  That will always run validation, which is disappointing due to the performance hit.  We've had to change to call a web service that calls our validation procedure when we need to validate, say a grid of 1 to 100 lines, via procedure, due to the performance.

Inputs/Outputs:  Any procedure input or output parameters are configured as separate Node Inputs, with the name matching exactly as defined in the procedure.  Inputs only need a Value setting, outputs only need Save Into.

If you have any specific errors or questions, let us know in the thread.