Run a task on an on-demand Databricks cluster
Spin up a Databricks cluster on demand, run a Spark job, then tear the cluster down automatically.
Gate IBM i COBOL batch job submissions on returned message severity and alert Slack on critical messages or connection failure.
SBMJOB returning without an exception does not mean the submission was clean; IBM i can still hand back high-severity system messages that a script checking only the exit code would never see. This blueprint submits a batch job on a schedule, inspects every returned message for severity at or above a threshold, and pages Slack the moment one crosses it or the system cannot be reached at all.
submit_batch_job (io.kestra.plugin.cobol.SubmitJob) submits as400_program from as400_library to as400_job_queue via SBMJOB and captures the IBM i system messages returned during submission. allowFailure: true means a connection or authentication failure still lets the flow continue instead of aborting.classify_submission_health (io.kestra.plugin.core.debug.Return) checks whether outputs.submit_batch_job.messages is defined; if not, UNREACHABLE. Otherwise it runs a jq filter counting messages whose severity is at or above message_severity_threshold, returning CRITICAL when that count is above zero, HEALTHY otherwise.route_by_submission_health (io.kestra.plugin.core.flow.Switch) branches on that string: HEALTHY logs a quiet confirmation, CRITICAL pages Slack with the job identity, UNREACHABLE pages Slack separately, and defaults logs the raw outcome.log_audit_status records a status line on every run regardless of branch, so the execution history is a continuous submission-health trend.errors block pages Slack separately if the flow itself fails outright.as400_compliance_gate_schedule trigger polls every 6 hours with explicit input overrides, shipped disabled: true until you point it at a real IBM i system.status output (HEALTHY / CRITICAL / UNREACHABLE) you can chart or gate other flows on.A cron-triggered SBMJOB from a shell script tells you nothing once the command returns. This flow keeps every submission and every returned message in the execution history, turns the severity check into a typed output other flows can depend on, and gives you a Switch branch to grow into real remediation (resubmitting, paging the on-call operator, opening a ticket) without rewriting the check itself.
IBM_I_HOST: hostname or IP address of the IBM i system.IBM_I_USER: IBM i user profile to authenticate with.IBM_I_PASSWORD: password for that user profile.SLACK_WEBHOOK_URL: Slack incoming webhook used for the critical alert, the unreachable alert, and the flow-failure alert.SECRET_IBM_I_HOST, SECRET_IBM_I_USER, SECRET_IBM_I_PASSWORD, and SECRET_SLACK_WEBHOOK_URL as base64, for example echo -n "<your-host>" | base64.IBM_I_HOST, IBM_I_USER, IBM_I_PASSWORD, and SLACK_WEBHOOK_URL secrets.as400_library, as400_program, and as400_job_queue to a real, low-risk program you can submit repeatedly.status reads HEALTHY.as400_compliance_gate_schedule.jobName/jobNumber/jobUser) in a KV store to cross-reference against a later completion check.