System Parameters

The same set of system Parameters are included in all Execution Setups.

You can modify the Execution Setup to change the choices available to the person who uses the submission screen to submit a job. Each system Parameter is described below.

The standard system Parameters are described below.

To modify system Parameters, do the following:

Click the System Parameters subtab in the Execution Setup screen. The System Parameters screen opens.
Click the Update button in the System Parameters subtab.
You can modify the settings for any system Parameter as follows:
- Select one of the following:
  - Visible. The Parameter is visible and its value is modifiable in the submission screen. This is the default value.
  - Read Only. The Parameter is visible but not modifiable in the submission screen.
  - Hidden. The Parameter is not visible or modifiable in the submission screen.
- Allow. Each system Parameter has a defined list of values. Select the checkbox for each value you want to make available to the user.
- Default (Optional). Set one of the allowed values as the default by clicking the radio button in the Default column next to the value. This value appears as the default value in the Submission screen.
  
  Note:
  If you are defining an Execution Setup for backchaining, for scheduled submission, or for triggered submission, you must define a default value for each Parameter, including the system Parameters.

The system Parameters are:

Submission Type: This system Parameter determines which submission methods this Execution Setup accepts:

Deferred. A deferred submission runs once at a future scheduled time. Either you, working in the Execution Setup definition, or a user working in the Reports tab, can schedule the job to run one time in the future.
Immediate. An immediate submission runs as soon as possible. Either you, working in the Execution Setup definition, or a user working in the Reports tab, can submit the job for immediate execution.
Scheduled. A scheduled submission runs repeatedly on a regular schedule. Either you, working in the Execution Setup definition, or a user working in the Reports tab, can schedule the job to run on a regular basis in the future.
Backchain. Backchain Execution Setups are called by another job—one that operates on data that has been loaded or generated directly or indirectly by this Program or Load Set—that has been submitted with the Data Currency Parameter set to Most Current Data Available. Users cannot submit a job for a backchain execution. They can, however, submit an immediate, deferred, or scheduled job that starts the backchain process.

Note:

If you define a backchain Execution Setup, you must click Submit when you are finished. This creates a job of submission type Backchain that waits until triggered by a backchain process. The Execution Setup will not run during an actual backchain process unless you have already submitted it.
Triggered. The Execution Setup accepts an XML message sent from an external system as the trigger for submission. For example, when Oracle Clinical batch validation has completed successfully, Oracle Clinical could send a message to trigger loading fresh data into Oracle Life Sciences Data Hub. Users cannot submit a job for a triggered execution.

Note:
When you define an Execution Setup to accept the Triggered submission type, allow Immediate and Deferred submission as well. The XML message must specify whether the job should be executed immediately upon receipt of the message or at a scheduled time in the future.

Notify on Completion: This setting determines when the person who submits a job using this Execution Setup receives a notification upon completion of the job:

Job Failure. The submitter receives a Notification only if the job fails.
Never. The submitter does not receive any Notification about the status of the job.
Job Success. The submitter receives a Notification only if the job succeeds.
Job Warning. The submitter receives a Notification only if the job ends with a status of Warning.

Data Currency: This system Parameter has the following allowed values:

Current Immediate Source. This is the standard setting. The system processes the most current data contained in the source Table instances (or, in the case of a Load Set, the source data system).
Most Current Available (Triggers Backchain). This setting invokes a backchaining job that reexecutes all Program and Load Set instances that directly or indirectly feed data into the source Table instances of the current executable, if they meet the following criteria:
- They have a submitted Execution Setup with a Submission Type of Backchain.
- Each executable instance between them and the current executable also has an Execution Setup with a Submission Type of Backchain.
- Their source data is more current than their target data.
Specify Snapshot. This setting enables the user to specify a particular labeled or timestamped snapshot of source data at a previous point in time to run the Program against. If you select Specify Snapshot, you may also want to set the following:
- Default Snapshot Label. From the drop-down list, select a snapshot label. This label will appear as the default value in the submission form. The drop-down list displays all snapshot labels shared by all source Table instances.
- Lock Default Snapshot Label. If set to Yes, the person submitting the Execution Setup cannot change data currency; the Data Currency subtab is Read Only. If set to No, the submitter can change data currency in the Data Currency subtab.

Execution Priority: Set this value to determine the priority the system gives to the execution of this job, compared to other jobs of the same technology type. The choices are High, Normal, and Low.

Submission Mode: When the target Table instances require Reload or Transactional High Throughput processing, you must specify Full or Incremental Processing. The default value is Full.

Note:

The system does not display the Incremental options for jobs that do not have Reload or Transactional High Throughput Table instances as targets.

Incremental mode for Reload processing. The system processes all records, compares the primary or unique key of each record to the current records in the table, and updates or inserts records as appropriate. Incremental mode never deletes records and therefore takes less time to complete.
Full mode for Reload processing. The system does the same processing as in incremental mode and then performs the additional step of soft-deleting all records that were not reloaded. Full processing takes more time to complete but accurately reflects the state of the data in the source.
Incremental mode for Transactional High Throughput processing. The system appends data to the Table after the last record. The system hard-deletes data if the Oracle LSH Program explicitly issues a Delete statement.
Full mode for Transactional High Throughput processing. The system truncates the existing Table and loads fresh data into it. In this mode, you will lose all the Blinded data in the Table, even if you run the job with the Dummy setting for Blind Break.

Note:
The default data loading mode is Full. If you do not want to lose all your existing data, change the data loading mode to Incremental.

You may decide to use incremental mode on jobs that are run frequently, but use full mode at regular intervals on the same jobs when you need the most accurate data.

Note:

The submission screen contains additional system Parameters that allow the user to apply a snapshot label to target Table instances or to target and source Table instances at runtime. The user must also supply the text of the label at runtime. See "Setting Submission Details and Data Currency" in the Oracle Life Sciences Data Hub User's Guide for further information.

Blind Break: This Parameter is relevant only when one or more source Table instances either currently or formerly contained blinded data. Special privileges are required to run a job on real, sensitive, blinded data and to see the resulting output. The values available to the Definer in the Execution Setup depend on the current Blinding Status of the source Table instances:

If none of the source Table instances has a Blinding Status, the only value available is Not Applicable. You may want to hide the Parameter (set it to Hidden) to avoid confusion.
If one or more of the source Table instances has a Blinding Status of Blinded, the values available include Real (Blind Break) and Dummy. You can make the Parameter Visible, allow both values, and make Dummy the default. Only users with Blind Break privileges on all blinded source Table instances will be able to select Real (Blind Break).
If you are using DMW and all source tables with a Blinding Status of Blinded are blinded at the column, row, or cell level (not the table level), the Dummy Blind Break option allows processing the masking values in LSH. These are stored in the Dummy partition of the target table(s).

Tip:
Oracle recommends processing DMW data in DMW, not LSH. In particular, do not run DMW transformations and validation checks in LSH.
If one or more of the source Table instances has a Blinding Status of Unblinded, and none of the source Table instances has a Blinding Status of Blinded, the values available include Real (Unblinded) and Dummy. You can make the Parameter Visible, allow both values, and make Dummy the default. Only users with Unblind or Blind Break privileges on all unblinded source Table instances will be able to select Real (Unblinded).

Note:
If you set the default value to Not Applicable or Dummy, the System Parameters subtab displays the default value as No. If you set the default to Real (Blind Break) or Real (Unblinded) the System Parameters subtab displays it as Yes.

Force Execution: If set to No, before running a job based on this Execution Setup, the system compares the following for the current job and for the previous time the same instance was executed and does not reexecute the job if all of the following are true:

The Program (or other executable) definition version is the same.
The Parameter values are the same.
The Source Job ID for the source Table instances is the same.

If all of the above are the same, then the same results should occur from running the job again. The system does not run the job and instead gives the user a message that it is a duplicate job. If any one of the above is different, the current job is not considered a duplicate of a past job and the system executes it.

If set to Yes, the system runs the job even if the data has not been refreshed, the Parameter settings are the same, and the Program version is the same.

Note:

In the case of a Report Set Execution Setup, the Report Set itself always executes, whether Force Execution is set to Yes or not. However, if Force Execution is set to No, the Programs in the Report Set do not run if the conditions outlined above are true. In addition, the Force Execution setting affects only Programs assigned to Report Set Entries that are selected for inclusion in the job.

Timeout Value: You can set a default timeout value—the length of time the system should continue to try to run the job after it has been submitted—by entering a number in the Default Value field and selecting a default unit of time (Minutes, Hours, Days, Weeks, Months). For example, if a report is scheduled to run once a day, a timeout period of 24 hours would prevent generating two reports for the same day. Alternatively, you can specify the allowed and default units of time without specifying a default value, and let the user set the value.

Apply Snapshot Label: The available values are:

None. Users cannot apply a snapshot label to any Table instances at runtime.
Both. Users can apply a snapshot label to both source and target Table instances at runtime.
Target. Users can apply a snapshot label only to target Table instances at runtime.

Select one of these values to be the default. You can also specify a default label.

Parent topic: Modifying an Execution Setup and Setting Parameters