Adding deployment warnings

Warning statuses provide a way to easily identify deployments that require closer inspection that had been marked during the process execution.

Adding warnings

The warning message will be determined by the process author at design time.

// post-processing script
var exit = properties.get('exitCode');


/* Set a warning
scanner.register('^Warning: ', function(lineNumber, line) {
    properties.put('ucdWarning', line);
});

scanner.scan();
*/


if (exit == 0) {
    properties.put('Status', 'Success');
}
else {
    properties.put('Status', 'Failure');
}

View process requests with warnings

Scan the request history to locate executions that have warnings set and easily trace the warnings back to their originating plug-in step. The history and execution log pages will display the status of the execution alongside a warning indicator with count of warnings. This indicator will only display if there are any warnings from child activities that have not been ignored. Users can click warning count to view the list of warning messages from the plug-in steps of the executed process activity.

The history page will display a Status column that shows the execution status (Success or Failure) and also the count of warnings that had been set for that process. No count will be given if no warnings were set.

The execution log page displays each step and child execution. When the steps have completed the Status column will display the count of warnings in the same manner as the Request History page. In addition to displaying how many warning messages were set on a step/execution, you can bring up the warning messages for that step and any child steps underneath it. Below is an example of what messages would be available at each step in the execution log page. The shell with warning steps set a warning message.

Success/Failure notifications include warnings

In addition to displaying the result status, the default deployment or process notification templates include the total count of warnings that have not been ignored. You have access to the warning messages if you choose to modify the default notification templates. Server upgrades will not modify existing notification schemes.

Behavior

Warnings set on plug-in steps are passed up to parent process. For example, if you have a component process which uses the plug-in step Add Warning and this component process is used in an application process, the warning would be available in the application process execution log and history.

Warning messages are stored in the workflow trace. Each activity trace may contain a field warningMessagecontaining the warning message if one is set. Workflow metadata will contain a count of warnings generated for each execution context to allow accessing the warning count without loading the workflow trace.

Activities can optionally ignore warnings from its child activities. An activity that can spawn child activities can be configured to ignore the warnings from its child activities. The UI has an option to ignore warnings from child activities. If the activity is configured to ignore warnings then any warnings set from child activities should not be included in the spawning-activity's execution log and process request history.

For example, a component process deployWithWarning will always set a warning message. There is an application process appProcess that runs an Install Component step that runs deployWithWarning but ignores warnings. After execution completion, the execution log and deployment history will show appProcess and the Install Component step was successful with no warnings. However if the execution log is expanded, deployWithWarning will show successful with 1 warning.

Existing History and Execution Log