Property Name | Type of Data | Description |
|---|
AGENT_CONNECTION_TIMEOUT
| Integer | Enter a maximum period of time in minutes that the Deploy Job can wait after the Application Server loses contact with the target server. If the specified period of time elapses, the job fails.
If you do not enter any value or you enter 0, the job waits indefinitely. |
AGENT_QUEUE_WAIT_TIMEOUT
| Integer | Enter a maximum period of time in minutes that the Deploy Job can wait for the agent on the target server to process this Deploy Job. Waits typically occur when agents have queued Deploy Jobs. If the specified period of time elapses, the job fails.
If you do not enter any value or you enter 0, the job waits indefinitely. |
BY_PHASE_ALL_HOST_MUST_PASS_COMMIT
| Boolean | Enter True to instruct the job to undo the Commit phase for all target servers if any servers do not successfully complete the Commit phase. By default this option is set to False. This option is only applicable when the FLOW_CONTROL option is set to ByPhase. |
COPY_LOCKED_FILES
| Boolean | Enter True to instruct a target server to create "copy on boot" files when locked files are encountered during the Commit phase of a Deploy Job.
Entering False means the job generates an error and fails if it encounters locked files.
Note that a Deploy Job only creates "copy on boot" versions of read-only files if the OVERWRITE_READONLY_FILES option is set to True. |
DEPLOY_JOB_TYPE
| Enumerated | Specify the Deploy Job type: - Basic — Defines the job so if it fails, it is automatically reset, which means you can immediately run the job again. Also, basic BLPackage Deploy Jobs are defined to flow by server rather then by phase. Basic BLPackage Deploy Jobs are recommended if you are including the job in a Batch Job. This option is set to Basic by default.
- Advanced — Provides full flexibility when defining the job. For advanced BLPackage Deploy Jobs, you can choose to control the flow of the job by server or by phase and schedule execution of each job phase. If the job fails to complete, you can re-execute it on a server-by-server and phase-by-phase basis rather than have the job automatically reset.
|
ENABLE_SINGLE_JOB_MODE
| Boolean | Enter True to instruct the Deploy Job to run in single-job mode — that is, it cannot run in parallel on a target server with any other Deploy Jobs.
A job in single-job mode can only run when no other Deploy Job is currently being processed on the same target server. If other Deploy Jobs are processing, this Deploy Job waits until they are complete. While this job is being processed on a target server, no other Deploy Job can run. |
FLOW_CONTROL
| Enumerated | Specify how you want to control the flow of a job by choosing one of the following: - ByPhase — The job completes a phase on all servers before it proceeds to the next phase. This option is useful when you want a deployment to be completely successful, such as when you are updating a web application. This option is set to ByPhase by default.
- ByServer — The job proceeds as far as it can for each server. When one server fails, the job continues on other servers. When all servers have completed a phase (either by succeeding or failing), the job continues to the next phase for all servers that successfully completed the previous phase. This option is useful when you want the job to complete on as many servers as possible. A failure on one server does not impede the job on other servers.
|
FOLLOW_SYMLINKS_ON_URL
| Boolean | Enter True if a Deploy Job should copy the target of a symbolic link included in a URL; enter False if a Deploy Job should copy only the symbolic link itself. This option only applies when you are using the "Copy to Agent at staging" option to provide a URL that identifies source files for a patch or software package. |
IGNORE_COPY_ON_BOOT_FILES
| Boolean | Enter True to instruct a server to begin the Commit phase of the Deploy Job even though a server requires a reboot to copy over existing locked files.
Entering False means the Commit phase does not begin if locked files requiring a reboot exist. |
IS_ALLOW_ROLLBACK
| Boolean | Enter True to instruct the Deploy Job to leave rollback files on the target server so they can potentially be used later. In some situations the rollback files left on the target server can be very large. |
IS_AUTO_ROLLBACK
| Boolean | Enter True to instruct the Deploy Job to leave the destination host unchanged should the Commit phase fail.
When you set this option to True and the Commit phase fails for any reason, the Deploy Job is automatically rolled back, leaving the destination host unchanged. If you set this option to False and the Commit phase fails, the deployment aborts and does not roll back any transactions that are part of the deployment. |
IS_COMMIT_ENABLED
| Boolean | Enter True to enable the Commit phase of the Deploy Job. During the Commit phase, packages are applied to target servers. |
IS_RECONFIGURE_REBOOT
| Boolean | Enter True if any end-of-job reboots specified in REBOOT_OPTIONS should be Solaris reconfiguration reboots. |
IS_SIMULATE_ENABLED
| Boolean | Enter True to enable the Simulate phase of the Deploy Job. The Simulate phase performs a dry run of a deployment without actually deploying a package. A dry run lets you review job results, see the server objects that are changed during deployment, and determine what actions, if any, are causing the deployment to fail (that is, to generate a non-zero return code). |
IS_STAGING_INDIRECT
| Boolean | Enter True to enable indirect staging, which means the Deploy Job delivers the package to a repeater. During the Commit phase, the package is applied to the target server.
Entering False means the job delivers the package directly to a target server.
Note: If you are staging indirectly, you must define a property that identifies a repeater for each target server. |
ITEM_RECONFIGURE_REBOOT_OPTIONS
| Enumerated | Specify how the Deploy Job should handle item-level reconfiguration reboots by selecting one of the following: - Use item defined reconfigure setting — Instructs the Deploy Job to use the reconfiguration reboot settings defined for objects being deployed. These reboots occur in addition to the end-of-job reconfiguration reboot setting specified in
IS_RECONFIGURE_REBOOT. - Ignore item defined reconfigure setting — Instructs the Deploy Job to ignore any reconfiguration reboot settings defined for objects being deployed, regardless of whether you specified an end-of-job reconfiguration reboot in
IS_RECONFIGURE_REBOOT. If you choose this option, only the reconfiguration aspect of the reboot is ignored. If an item definition calls for a reconfiguration reboot, a reboot still occurs but it is not a reconfiguration reboot.
|
LOGGING_LEVEL
| Enumerated | Specify the amount of logging information that the Deploy Job generates by choosing one of the following: - Errors only — Only errors are displayed and output to a log.
- Errors and warnings — Errors and warnings are displayed and output to a log.
- All information — All messages, including errors and warnings, are displayed and output to a log.
|
OVERWRITE_READONLY_FILES
| Boolean | Enter True to instruct a server to overwrite read-only files when read-only files are encountered during the Commit phase. |
PRESERVE_STAGING_DIR_ON_FAILURE
| Boolean | Enter True to retain data copied to a staging area on a target server even though the Deploy Job fails.
By default a Deploy Job deletes the staging directory on a target server when a failure occurs during any phase of the job. Preserving a staging area can potentially leave large files on a target directory after a job failure. |
REBOOT_OPTIONS
| Enumerated | Specify reboot behavior by choosing one of the following: - Use item defined reboot setting — Causes a target to reboot after an object in the BLPackage is processed if the instructions for that object call for a reboot. If the reboot setting for an object is By end of job, and a reboot is not scheduled for this job, then a reboot occurs at the end of the job.
- Ignore item defined reboot setting — Prevents a server from rebooting no matter how a package is defined unless the object being deployed includes an out-of-band reboot (that is, a reboot that is built into the object and is not part of the BLPackage instructions).
- Use item defined reboot settings and reboot at end of job — Causes a target to reboot after each object in the BLPackage is processed if the instructions for that object call for a reboot. In addition, at the end of the job a final reboot occurs if the last item in the job is not defined to reboot. If the last item is defined to reboot, only one final reboot occurs at the end of the job.
- Ignore item defined reboot settings and reboot at end of job — Prevents a server from rebooting during a job no matter how a package is defined unless the object being deployed includes an out-of-band reboot (that is, a reboot is built into the object and is not part of the BLPackage instructions). At the end of the job, the server reboots.
- Consolidate reboots until end of job — Prevents a server from rebooting unless the item being deployed includes an out-of-band reboot (that is, a reboot that is built into the object and is not part of the BLPackage instructions). If any job items are defined to reboot after deployment, those reboots are consolidated into one reboot at the end of the job. If no job items require a reboot, no reboot occurs at the end of job. If a deployment to Solaris target servers includes items that require a reconfiguration reboot, those reboot requests are consolidated and the reboot at the end of the job is a reconfiguration reboot.
Note: If a Deploy Job includes a reboot, the job must be executed in single-job mode. This prevents the reboot from interfering with other Deploy Jobs.
|
REGISTER_COM_COMPONENTS
| Boolean | Enter True to register COM objects during the Commit phase.
When a deployment adds a file with an extension of DLL, EXE, or OCX, the job determines whether the file is a COM object. If it is, the deployment registers the new object during the Commit phase. |
REGISTER_COM_COMPONENTS_FOR_UNDO
| Boolean | Enter True to register COM objects during the Undo phase.
If the Commit phase of a job run removes a file, the file is restored when that job run is undone. If the file has an extension of DLL, EXE, or OCX, the job determines whether the file is a COM object. If it is and this option was set to True during the Commit phase of the job run being undone, the file being restored is registered. |
RESET_JOB_ON_FAILURE
| Boolean | Setting this option to True allows a job to be run again even though the job failed at least one phase on at least one server. By default this option is set to False.
If you set this option to True, failed jobs are placed into a Reset state. If you do not set this option to True, a job cannot be run again until it completes successfully |
UNREGISTER_COM_COMPONENTS_FOR_COMMIT
| Boolean | Enter True to unregister COM objects during the Commit phase.
When a deployment removes a file with an extension of DLL, EXE, or OCX, the job determines whether the file is a COM object. If it is, the deployment unregisters the object during the Commit phase. |
UNREGISTER_COM_COMPONENTS_FOR_UNDO
| Boolean | Enter True to unregister COM objects during the Undo phase.
If the Commit phase of a job run adds a file, the file is removed when that job run is undone. If the file has an extension of DLL, EXE, or OCX, the job determines whether the file is a COM object. If it is and this option was set to True during the Commit phase of the job run being undone, the file being removed is unregistered. |
USER_MODE_OPTIONS_UNIX_ONLY
| Enumerated | Specify user mode behavior (only applicable to UNIX target systems) by choosing one of the following: - Use item defined user mode setting — When processing each object being deployed, this Deploy Job uses the user mode setting (single- or multi-user) defined for that object.
- Ignore item defined user mode setting — Prevents a server from entering single-user mode no matter how individual objects in the package are defined.
- Use single-user mode without reboot — This Deploy Job is processed on a target server using single-user mode. The job switches into single-user mode without first rebooting or shutting down.
- Reboot into single-user mode — This Deploy Job reboots or shuts down a target server so the server enters single user mode. The job is then processed using single-user mode.
|
