A Batch Schedule Spreadsheet Template
Overview
This appendix explains how to set up the Batch Schedule Spreadsheet template. The template was originally developed for internal Oracle use and has since been made available to System Integrators and Customers for customizing Retail Application provided Batch Schedules or for developing custom Schedules. For the latter use, custom Batch Schedules may be less complex and may not require some tabs and fields.
Structure
The purpose of this template is to design the batch metadata that can be seeded into a Batch Schedule within POM. A Batch Schedule, at minimum, must define a Nightly Flow, consisting of a start and end Job. The Recurring and Adhoc Cycles are optional and need not contain any Processes or Jobs in them.
The spreadsheet template has a default nightly flow pre-populated with start and end
Nightly jobs. These jobs are seeded with DUMMY
job type so that they
will be skipped during execution.
Tabs
The following tabs are available on the Spreadsheet Template.
Tab Name | Purpose |
---|---|
Schedule |
Defines the name, display schedule name and version of the Batch Schedule. |
Flow |
Defines all the Flows in POM. Since the Nightly Flow is already in-built within POM, this refers to the Flows on the Adhoc and Hourly Cycles. |
Process |
Defines all the Processes in POM, across all Batch Cycles. |
Job |
Defines all the Jobs in POM, across all Batch Cycles. |
FlowProcessMapping |
Creates mappings between Flows and Processes. |
ProcessJobMapping |
Creates mappings between Processes and Jobs and maintains the sequence order of jobs within a process and also the parameter value. |
Dependency |
Creates internal dependencies between Processes. |
Application |
Defines the Applications to which the Jobs belong. It also defines a mapping between an Application and the name of the Job Agent that must run those Jobs. |
Modules |
Defines Modules within Applications. These are mainly used to synchronize with the Modules defined for the Application in Retail Home. See Sync with MDF in the POM User Guide for further details. |
SystemOption |
Lists all the system options available to the Jobs at execution time. |
ThrottlingConfiguration |
Defines the throttle settings at an Application level. |
InterscheduleDependency |
Defines dependencies with a different Batch Schedule on the same POM instance |
ExternalDependencies |
Defines External Dependencies usually on a customer’s internal process |
BatchLinks |
Also known as Schedule Links. If the Nightly Flow is going to be invoked via a different Job on a different Schedule, then a Schedule Link can be defined. |
JobTypes |
Custom ReST based types of Jobs that need to be run |
Schedule Errors |
Empty tab that is populated with the list of errors, either by the macro or when being transformed by the Batch Schedule Transformer. |
Macro Validation
This Excel Template is equipped with a macro that can be run to validate the entries on the spreadsheet. Upon encountering failures, the macro publishes the error entries in the Schedule Errors tab.
Schedule Validation Processes
Applications can set up processes and jobs for use by the provisioning process to validate the setup. After POM has been provisioned/patched, the provisioning tool will attempt to run the validation job(s) to ensure that POM is functional end to end. Following are the steps to setup these processes/jobs:
-
In the Process tab, add new processes that end with
_POM_VPROCESS
. Examples:RMS_SALES_POM_VPROCESS
,REIM_EJB_POM_VPROCESS
-
In the Process tab, set the value in the AdhocInd field to
Y
because validation processes can only be part of the adhoc cycle. -
In the ProcessJobMapping tab, make sure the newly created validation processes are mapped to any valid job that shouldn’t run for more than 5 minutes. Validation jobs should obviously be benign in that they should not alter data.
-
If there is more than one job in a validation process, make sure the pre and post dependencies are correctly defined in the Dependency tab.
Schedule Upgrade Directives
These are directives solely to the Batch Schedule upgrade process, altering values as specified, when the default settings are not acceptable. For instance, all newly added Jobs are marked DISABLED by default. To enable a Job, the AMS team or the Customer is asked to do so through the POM UI. This is not ideal as it involves manual intervention. To overcome this, we use the “enableOnNew” directive on the Job tab, to ensure that the Job is marked ENABLED when its added for the first time.
The processing of these directives is designed as a stage in the Schedule Import process. The following directives are currently supported in POM.
Template Tab | Directive Name | Description |
---|---|---|
Job |
enableOnNew |
Only when being loaded for the very first time, the Job will be enabled. When this directive is not used, the job will be disabled by default when added for the first time. |
Job |
enableLikeJobOnNew |
Only when being loaded for the very first time, the status of the Job (for which the directive is specified) will match that of the “LikeJob”. |
Job |
enableLikePJOnNew |
Only when being loaded for the very first time, the status of the Job (for which the directive is specified) will match that of the “LikeProcessJob” defined. |
If any Process-Job combination has multiple directives that are semicolon delimited, they get executed in the following order:
-
enableOnNew
-
enableLikePJOnNew
-
enableLikeJobOnNew
Tab Definitions
Process Tab
This tab allows you to define all processes for the schedule at hand. A process is a group of jobs that are to be run sequentially from start to end. The following is a description of all fields on this tab:
-
ProcessName
-
Uniquely identifies a process. The Process Name should be in upper case only with no spaces. Use an underscore if needed. It should end with
XXX_PROCESS
. Validation processes should end with_POM_VPROCESS
.See Schedule Validation Processes above for an explanation of the validation processes.
-
The process name is the batch job name appended with
_PROCESS
.For example:
DEALUPLD_PROCESS
SA_TRANSACTION_LOADING_PROCESS
-
For non-Merchandising processes, the process name should start with the Application name.
For example:
REIM_POSTING_PROCESS, ALC_DAILY_CLEANUP_ PROCESS
-
If a process is part of the nightly batch cycle but is also an ad hoc job, or if it’s also part of a recurring flow, three separate processes should be defined. The ad hoc process should end with
XXX_PROCESS_ADHOC
and the recurring process should end withXXX_CYCLE_PROCESS
.For example:
-
SA_TRANSACTION_LOADING_PROCESS
– for the sales audit transaction loading jobs that will run in the nightly batch cycle. -
SA_TRANSACTION_LOADING_PROCESS_ADHOC
– for the sales audit transaction loading jobs that will run ad hoc. -
SA_TRANSACTION_LOADING_CYCLE_PROCESS
– for the sales audit transaction loading jobs that will run multiple times a day.
-
-
-
Description
-
Short description of the process. There should be no special characters. If the process contains just one job, the description can be the same as the batch job name.
-
-
DependencyType
-
Valid values are
TIME
,JOB
andBOTH
. -
If the first job in this process is triggered on completion of another job, mark as
JOB
. -
If the process is scheduled to run at a specific time (for example, the first job of the nightly batch cycle, or part of a recurring flow process), mark as
TIME
. -
If the process needs to run at a specific time and at the same time is dependent on another process, mark as
BOTH
. -
If the process is ad hoc and is not part of the nightly batch cycle, leave as
NULL
.
-
-
ApplicationName
-
This holds the application name which the batch process belongs to.
-
Valid values are
RMS
,RPM
,REIM
,RESA
,ALLOC
,RDE
,MFP
,AIPFSL
,RDF
, and so on.
-
-
AdhocInd
-
Valid values are
Y
andN
. -
If the job(s) in the process are ad hoc jobs (can be run any time and not part of the nightly batch cycle), mark as
Y
. Otherwise, mark asN
. -
A process should not have a mix of ad hoc and scheduled jobs in it.
-
Job Tab
The Job tab contains all the individual jobs to be executed as part of the schedule at hand.
-
JobName
-
Uniquely identifies a job. The Job Name should be in upper case only with no spaces. Use an underscore if needed. It should end with
XXX_JOB
. If the same job is part of multiple processes, define separate jobs for it.Examples:
-
EXPORT_DIFFS_JOB
(underEXPORT_DIFFS_PROCESS
) – for theexport_diffs.ksh
program passing in ‘delta’ as a parameter -
EXPORT_DIFFS_FULL_JOB
(underEXPORT_DIFFS_FULL_PROCESS
) – for the sameexport_diffs.ksh
program but this time passing in ‘full’
-
-
For non-Merchandising jobs, the job name should start with the Application, (for example,
REIM_POSTING_JOB
,ALC_DAILY_CLEANUP_JOB
,RDE_SEASNSDE_JOB
) -
If the job is part of the nightly batch cycle and is also part of a recurring flow, define two separate jobs for it.
Examples:
-
UPLOADSALES_JOB
belonging toSALESPROCESS_PROCESS
– for theuploadsales.ksh
program run as part of the nightly batch cycle -
UPLOADSALES_CYCLE_JOB
belonging toSALESPROCESS_CYCLE_PROCESS
– for the sameuploadsales.ksh
program run as part of a recurring flow
-
-
-
Description
-
Short description of the batch program. There should be no special characters.
-
-
RmsBatch
-
This holds the exact batch executable that the job refers to. For Pro*C programs, this should be the binary without the
.pc
extension. For KSH scripts, include the.ksh
extension. This field is case-sensitive. -
For service type jobs (non-shell script EXEC type jobs), this field should be left blank.
-
-
RmsWrapper
-
If applicable, this holds the exact batch wrapper name used to call the batch program. This field is case-sensitive.
-
For service type jobs (non shell script EXEC type jobs), this field should be left blank.
-
-
ScriptFolder
-
This holds the directory path where the Wrapper file resides in the system.
-
For service type jobs (non-shell script EXEC type jobs), this field should be left blank.
-
-
ParameterValue
-
This holds the entire parameter value to be passed in to a shell script type job. This field is case sensitive.
-
For parameters that can have multiple values (for example, purge days parameter), provide a default value so that the batch can still be executed.
-
Placeholder parameter
#JobCtxt.businessDate
can be defined on the Job sheet for jobs that require a POM business date parameter (DDMMYYYY
format).
-
-
Parameters are updated in the
BASE_PARAMETER
column of theBATCH_PROCESS_JOB_LIST
table. On a schedule upgrade, theACTIVE_PARAMETER
column value is updated with theBASE_PARAMETER
only if the parameter value has never been changed from the UI. -
ApplicationName
-
This holds the application that the batch program belongs to.
-
It should be a valid application mentioned in the Application tab.
-
-
Module
-
This holds the name of the module under the application which the batch program belongs to. The Application / Module entered here should be a valid combination in the Application tab.
-
If there are no modules defined for the corresponding application in the Application tab or the Modules tab, then this column can be left blank. Otherwise it is required to enter the module(s) it belongs to.
-
A job can belong to multiple modules under the same application. In this case the list of those modules should be entered here with
||
as a delimiter.For example:
MODULE1||MODULE2||MODULE3
-
If the corresponding Application have some modules defined in Application Sheet then this column cannot be left blank.
-
-
FixedParameterInd – VARCHAR(1)
-
Valid values are
Y
andN
. -
This indicates whether the parameter value can be changed on the Batch Administration screen. If this is
Y
, the parameter will be changeable on the UI. This is applicable if the parameter cannot have a default value, or if the parameter can have different values. -
If this is
N
, the parameter value is fixed and will not be changeable on the UI.
-
-
ParameterUpdated – VARCHAR(1)
-
Valid values are
Y
andN
. -
This indicates whether the parameter value column has changed from the previous value.
-
If
Y
, then the parameter value is passed and updates the existing job information with the newly passed parameter value. IfN
the parameter value won’t be updated for the existing job information.
-
-
SkipOnError – VARCHAR(1)
-
Valid values are
Y
andN
. -
A value of
Y
indicates that the job should be skipped if an error occurs and the batch schedule continues to run. Otherwise the batch schedule is stopped.
-
-
JobType – VARCHAR (50)
-
The default value set is
EXEC
, which represents shell-script based Jobs. Other pre-defined service based job types areRI
,RASE
,BDI
,RPAS
,OMS
,OB
,RDS
, andDUMMY
. -
Custom Job types defined in the JobType tab can also be used in this field. In this case POM is directed to execute the job using the endpoint defined on the JobType tab.
-
-
KillCleanupScript – VARCHAR (1000)
-
Absolute path of the cleanup script to be run after killing a shell script (
EXEC
) type job from the POM UI. Example:/u01/retail/rms/batch/outgoing/app_cleanup_script.sh
-
Can include arguments as well along with the script.
The post-kill cleanup script is executed automatically by POM after a Kill is performed from the UI. It does not perform the kill itself. It is defined by the application teams such as Merch. Here's how it works: The user performs a Kill on a running job from the POM Batch Monitoring screen. If a
KillCleanupScript
is defined for that job on the Job worksheet of the batch schedule spreadsheet, POM will execute it after killing the job on the server. Application teams usually include database clean-up as part of the clean-up script.For example:
-
ProcessJob Mapping
The ProcessJobMapping tab allows you to map or group jobs within processes.
-
ProcessName – VARCHAR(50)
-
This should match the ProcessName in the Process tab.
-
-
Job Name – VARCHAR(50)
-
This should match the JobName in the Job tab.
-
-
Job Sequence – NUMBER(4)
-
Contains the sequence of execution for the Job in a Process starting from
1
for the first job in a Process. This number must be unique and contiguous for a process. -
Valid values are
1
to9999
.
-
-
DayOfTheWeek – VARCHAR(100)
-
Contains the day(s) of the week on which the specific Process/Job needs to run. POM automatically skips these Jobs on the remaining days.
-
This field is optional, leaving it blank will cause the Job to run on a daily basis.
-
-
Priority – NUMBER (2)
-
Contains the Priority set for the specific Process / Job.
-
A simple number representing the priority at which a job will run in a throttled setting compared to other jobs that are set to run concurrently
-
Valid values: 1 to 10 with 10 being the highest priority and 1 being the lowest
-
This field is optional, leaving it blank will set the priority to the default value of zero.
-
-
Phase – VARCHAR (50)
-
Contains the Phase name designated for the Process / Job.
-
This grouping of jobs in the Nightly cycle is used for reporting purposes only. Nightly Summary Report will then report total run time and elapsed time by Phase.
-
This field is optional, leaving it blank will default the phase to Others.
-
-
Directive – VARCHAR (200)
-
Contains the directive for Process / Job.
-
Enables/disables a new Job according to the directive provided.
-
Valid values: enableOnNew, enableLikePJOnNew, enableLikeJobOnNew. See the Schedule Upgrade Directives section above for more details on the use of these values.
-
This is an optional column. Leaving it blank will create the job as disabled.
-
The value of this column is a semi-colon separated string of directive key-value pairs. A process job can have one or more than one directive defined.
-
-
ParameterValue–VARCHAR(2000)
-
Parameter value for the process–job combination.
-
Value will be updated during schedule patching only if the value has never been updated using the UI.
-
This field should be part of either the Job sheet or the ProcessJobMapping sheet.
-
Example
If a process has 2 jobs in it, then there should be 2 entries in this tab for each job.
![ProcessJob Mapping ProcessJob Mapping](img/processjobmapping.png)
Dependency Tab
The Dependency tab allows you to define the dependencies between processes.
-
ProcessName – VARCHAR(50)
-
This should match the ProcessName in the ProcessJobMapping tab.
-
-
PredecessorProcessName – VARCHAR(50)
-
This holds the process name that should run before the current job. This can be the same process (if there are multiple jobs in the process) or a different process than the current one.
-
Example
ProcessName | PredecessorProcessName |
---|---|
SAPURGE_PROCESS |
SAEXPRMS_PROCESS |
SAPURGE_PROCESS_START |
SAPURGE_PROCESS |
SAPURGE_PROCESS_END |
SAPURGE_PROCESS_START |
Note:
Dependencies between adhoc processes of named adhoc flow / invokable flow can also be defined in this tab.If an invokable flow only contains one adhoc process, there’s no need to fill up the Dependency tab for such flow.
If an invokable flow has more than one adhoc process, the dependencies of processes 2, 3, and so on need to be defined. There is no need to define the dependency of the first process, because this will not be dependent on another process.
Example
The invokable / named adhoc flow FCUSTOMERUPLOAD_ADHOCFLOW
has 2 processes:
-
FCUSTOMERUPLOAD_PROCESS_ADHOC
-
FCUSTOMERPURGE_PROCESS_ADHOC
Only the dependency of the second process (FCUSTOMERPURGE_PROCESS_ADHOC
) needs to be defined:
ProcessName | PredecessorProcessName |
---|---|
FCUSTOMERPURGE_PROCESS_ADHOC |
FCUSTOMERUPLOAD_PROCESS_ADHOC |
Flow Tab
The Flow tab allows you to define jobs that runs Adhoc flows and hourly or multiple times a day.
-
RecurringFlowName – VARCHAR(50)
-
Uniquely identifies the recurring flow / adhoc flow. The Recurring Flow Name should be in uppercase only with no spaces. Use an underscore if needed. It should end with
XXX_CYCLE
.
-
-
Description – VARCHAR(50)
-
Short description of the recurring / adhoc flow. There should be no special characters.
-
-
NumberOfRuns – NUMBER(2)
-
This contains the number of runs for this recurring flow in a day.
-
Valid values are
1
-24
. For hourly runs, maximum value is12
. For half hourly runs, the maximum value is24
.
-
-
Interval – NUMBER(2)
-
The interval between job runs. The Interval is specified in hours. Upper Limit is
12
.
-
-
StartTime – VARCHAR(50)
-
The time for the first batch run.
-
-
AdhocInd – VARCHAR (1)
-
Indicates if flow belongs to adhoc flow or not.
-
Valid values: Y/N
-
Example
AdhocFlowTest1 and AdhocFlowTest2 are the adhoc flows with AdhocInd set to Y. HourlCycle is the hourly cycle defined to run 4 times at an interval of 4.
![Example Flow Example Flow](img/example-adhoc-flow.png)
FlowProcessMapping Tab
The FlowProcessMapping tab allows you to define the processes for each recurring / adhoc flow defined in the Flow tab.
-
RecurringFlowName – VARCHAR(50)
-
This should match the RecurringFlowName in the Flow tab.
-
-
ProcessName – VARCHAR(50)
-
This holds the process name(s) that are part of the recurring/ adhoc flow.
This should match the ProcessName in the Process tab. A recurring / adhoc flow can have more than 1 process.
-
-
FirstProcessInd – VARCHAR(1)
-
Valid values are
Y
andN
. -
If the process holds the first job of the recurring / adhoc flow, mark as
Y
. Otherwise, mark asN
.
-
-
LastProcessInd – VARCHAR(1)
-
Valid values are
Y
andN
. -
If the process holds the last job of the recurring/ adhoc flow, mark as
Y
. Otherwise, mark asN
.
-
Example
The SALESPROCESS_CYCLE
recurring flow has only 1 process, so the first
and last jobs of the recurring flow is in the same process.
The REPLENISHMENT_CYCLE
recurring flow
has multiple processes. The first job of the recurring flow is in the first process, and the last job is in the last process.
RecurringFlowName | ProcessName | FirstProcessInd | LastProcessInd |
---|---|---|---|
SALESPROCESS_CYCLE |
SALESPROCESS_CYCLE_PROCESS |
Y |
Y |
REPLENISHMENT_CYCLE |
REPLENISHMENT_CYCLE_PROCESS |
Y |
N |
REPLENISHMENT_CYCLE |
SUPSPLIT_CNTRPRSS_CYCLE_PROCESS |
N |
N |
REPLENISHMENT_CYCLE |
INVESTMENT_BUY_CYCLE_PROCESS |
N |
N |
REPLENISHMENT_CYCLE |
RPLBLD_CYCLE_PROCESS |
N |
N |
REPLENISHMENT_CYCLE |
REPLENISHMENT_END_CYCLE_PROCESS |
N |
Y |
AdhocFlowTest1 |
APIPGHL_ADHOC_PROCESS |
Y |
Y |
AdhocFlowTest2 |
RDF_ADHOC_PROCESS |
Y |
Y |
SystemOption Tab
The SystemOption tab contains the system level options used to control certain aspects of the POM application, such as whether to enable throttling. It can also be used to define shell script error or warning exit codes. If any such codes are specified, they will cause a shell script based job to fail or complete with warning.
This tab can be left blank for service (non-EXEC) type jobs.
-
Name – VARCHAR(255)
-
Holds the name of the System Option value needed in JOS; for example,
enableThrottling
,WarningCode110
,ErrorCode40
,RIRestartableErrorMessages
,TARGET_BATCH_DURATION
.A value of
WarningCode110
, for example, causes POM to mark the job status as completed with a warning if the job’s shell script exits with a code of 100. A value ofErrorCode40
, for example, causes POM to mark the job status as error if the job’s shell script exits with a code of 40.For a value of
<<JOB_TYPE>>RestartableErrorMessages
, the description field holds a list of comma-separated error messages that determine the auto-restart capability of the jobs. If the response contains one of those error messages, POM will retry the job for a maximum of 3 attempts.For example, to add this capability to the RI Job Type when encountering either of the messages "context not found" or "500 internal error".
-
-
Type – VARCHAR
-
Valid values are
Process
andJob
(for example,Job
for system optionenableThrottling
or error/warning shell script exit codes or Restartable Error Messages). -
This defines the JOS admin component the System Option is for.
Job
is forJosJobAdmin
andProcess
is forBdiProcessFlowAdmin
.
-
-
Description – VARCHAR(255)
-
This holds the value for the System Option. For example,
TRUE
for system optionenableThrottling
, or the error/warning message to be conveyed in the notification sent in the case of an error/warning shell script exit codes, or the error messages to determine whether to auto-restart rest-based jobs or not, or the number of minutes for theTARGET__BATCH_DURATION
. The system options value changes are updated during schedule patching.Here's an example SystemOption tab with all the aforementioned system options:
-
Application Tab
The Application tab allows you to define the Application name and its modules.
-
Name – VARCHAR(50)
-
Holds the name of the application supported in the schedule (for example,
RMS
,RI
,RDS
). -
This cannot be blank.
-
-
Description – VARCHAR(1000)
-
Description of the application.
-
-
Modules – VARCHAR(50)
-
List of module name(s) associated with the Application.
-
||
is used as delimiter (for example,MODULE1||MODULE2||MODULE3
) -
This field can be blank when there are no modules defined for the Application.
-
If the module list is large (> 3000 chars), rather than filling modules in this field, list all modules in Modules tab. If larger than 3000 chars, the schedule generation will fail. If you decide to use the Modules tab, the modules in this field in the Application tab need to be blank, as it directs POM to look for modules in the Modules tab instead.
-
-
JosJobAdminName – VARCHAR(50)
-
Corresponds to the Job Admin name (in POM version 19.x) or Agent name (in POM version 22.x or later) for the application. This usually is the same or similar name to the application name.
-
This cannot be blank.
-
Example
-
Application with modules defined.
Name Description Modules JosJobAdminName COMMON
All apps required programs
COMMONMAINTAIN||PRE_VERIFY||CALENDAR||COMMONPRODUCT||COMMONORG||COMMONPROMO||EMPLOYEE||COMMONCO||COMMONSALES||REASON||COMMONAC||COMMONCS||COMMONASO||COMMONCDT||COMMONDT
RIS1
ORASERCI
ORASE and RCI required programs
ORASERCICUSTOMER||CONSUMER||CATMAN||ORASERCIMARKET||TRADEAREA||CUSTSEG||MARKETAGG||ORASERCIAC||ORASERCICS||ORASERCIASO||ORASERCICDT||ORASERCIDT
RIS2
RCI
RCI required programs
RCICUSTOMER||LOYALTY||PROMOFORECAST||RCIMARKET
RIS1
RSP
RSP required programs
AC||CS||ASO||CDT||DT
RIS1
-
Applications without any modules defined.
Name Description Modules JosJobAdminName RMS
RMS
RMS
ALLOC
ALLOC
RMS
RDE
RDE
RDE
REIM
REIM
RMS
RESA
RESA
RMS
RPM
RPM
RMS
Schedule Tab
The Schedule tab contains the name of the schedule along with version and description. Increasing the version is necessary to upload a spreadsheet with any changes to POM.
-
ScheduleName – VARCHAR(10)
-
Holds the name of the Schedule (for example,
MERCH
,RDE
, orRI
).
-
-
Description – VARCHAR(100)
-
Description of the Schedule.
-
-
Version – VARCHAR(50)
-
Version of the Schedule.
-
-
DisplayScheduleName – VARCHAR(1000)
-
Holds the display name of the Schedule (for example,
MERCH
,RDE
, orRI
). -
Optional field. If a value is not provided, value in the ScheduleName field will be used as the display schedule name.
-
Display schedule name will be used in the UI, reports and e-mails.
If a display schedule name value is not provided on the batch schedule spreadsheet, it can be provided at a later time through the UI. To accomplish that, an entry can be added in the SystemOptions panel from the System Configuration screen.
Example:
Key: displayScheduleName
Value: MERCHANDIZE
-
This tab cannot be empty for any given schedule.
ThrottlingConfiguration Tab
The ThrottlingConfiguration tab contains the Application / Module Level throttling values. Throttling determines how many
jobs can run concurrently for the given application, so a value of 10
means a maximum of ten jobs can run
concurrently. It is advisable to leave this tab empty unless you have good knowledge of the server memory and CPU capacity.
-
Application – VARCHAR(50)
-
Holds the valid application name for which we need to set a throttle value.
-
If an entry is made in this tab, the Application can’t be blank and should be the value listed in Application tab.
-
-
Module – VARCHAR(50)
-
Holds the module name in the case where we need to set a throttle value at module level.
-
It is possible to just set throttling at the application level. Modules would then inherit the application’s throttle value. In this case, leave module blank.
-
This Application / Module combination must be valid per the Application tab.
-
-
ThrottledValue – NUMBER
-
Holds the throttle value for this Application / Module.
-
This can’t be blank and should be a non-zero positive number.
-
Example
-
For an Application without any modules defined.
Application Module ThrottledValue RMS
2
ALLOC
5
REIM
3
RDE
2
-
For an Application with modules defined, define throttle values at either application or module level or both.
Application Module ThrottledValue COMMON
3
COMMON
COMMONMAINTAIN
1
ORASE
2
If you don’t want any jobs to be throttled at Application / Module level, then leave this tab empty.
InterScheduleDependency Tab
The InterScheduleDependency tab allows you to define dependencies from jobs on this schedule to jobs on other schedules on the same instance of POM. For example, job A of this schedule can be made dependent on job B from another schedule. Job A will then wait for completion of job B.
-
ProcessName – VARCHAR(50)
-
Holds the name of the process from the current schedule that is dependent on a different schedule.
-
This process name should be listed in the Process tab.
-
-
JobName – VARCHAR(50)
-
Holds the name of the corresponding job within the above process that has the dependency on another external schedule.
-
This Process Job combination should be valid per the Process Job Mapping tab.
-
-
ExternalScheduleName – VARCHAR(10)
-
Holds the name of the external schedule that contains the dependency.
-
-
ExternalPredecessorProcessName – VARCHAR(50)
-
Holds the name of the process that contains the job from an external schedule which needs to complete before the job in the current schedule starts running.
-
-
ExternalPredecessorJobName – VARCHAR(50)
-
Holds the name of the corresponding job (from the external schedule) that must complete before the job in the current schedule starts running.
-
Example
![Example Inter Schedule Dependency Tab Example Inter Schedule Dependency Tab](img/inter_sched_depend_tab.png)
If there are no inter schedule dependencies for any jobs in the schedule, then leave this tab empty.
Modules Tab
The Modules tab allows you to define the mapping between the POM Modules and the Module Definition Framework (MDF) Modules. It also serves a second purpose by defining the modules for an application. If the module field on the Application tab is not blank, POM will use those modules. Otherwise, if blank, POM will use the modules from this tab.
MDF holds the applications and modules to which a customer has subscribed. POM can then optionally sync with MDF to activate or deactivate applications and/or modules.
-
Application – VARCHAR(50)
-
Holds the valid application name for which we need to set an MDF Module Path.
-
This can’t be blank and should be listed in Application tab.
-
-
Module – VARCHAR(50)
-
Holds the module name for cases when the MDF Module Path must be set at module level.
-
This can be blank when the MDF Module Path is only set at the application level.
-
This Application / Module combination should be valid per the Application tab.
-
-
MDFModulePath – VARCHAR(4000)
-
Holds the module path in the MDF application.
-
This can’t be blank. This should be a slash (
/
) separated path.For example:
/RMS
,/COMMON/COMMONAC
-
Example
![Modules Tab Modules Tab](img/modules_tab.png)
ExternalDependencies Tab
This tab allows you to define the dependencies of POM jobs on external schedulers like Ctrl-M.
-
ProcessName – VARCHAR(50)
-
Holds the name of the process in the current schedule for which the external job is to be configured.
-
This process name should be listed on the Process tab.
-
-
JobName – VARCHAR(50)
-
Holds the name of the corresponding job of the above process for which the external job is to be configured.
-
This Process Job combination should be valid per Process Job Mapping tab.
-
-
ExternalPredecessorJobName – VARCHAR(300)
-
Holds the name of the external job that needs to complete before the job in the current schedule can start.
-
Example
![Example External Dependencies Tab Example External Dependencies Tab](img/extern_depend_tab.png)
BatchLinks Tab
This tab contains Batch Links. When you set up a batch link, you direct POM to start a job in schedule B upon completion of a job in schedule A. It’s a way of linking two schedules together and having one start the other. You want the job in schedule B to be the first job of the schedule.
If no such link is desired, leave this tab empty.
-
ProcessName – VARCHAR(50)
-
Holds the name of the process in the current schedule that needs to be invoked by a process / job from an External Schedule.
-
This process name should be listed in Process tab.
-
-
JobName – VARCHAR(50)
-
Holds the name of the corresponding job of the above process that needs to be invoked from the other external schedule.
-
This Process Job combination should be valid as per the Process Job Mapping tab.
-
-
InvokerScheduleName – VARCHAR(10)
-
Holds the name of the external schedule whose job is to invoke the current schedule’s job.
-
-
InvokerProcessName – VARCHAR(50)
-
Holds the name of the process in the invoking schedule.
-
-
InvokerJobName – VARCHAR(50)
-
Holds the name of the corresponding job from the invoking schedule.
-
Example
![Example Batch Links Tab Example Batch Links Tab](img/batch_link_tab.png)
If there are no batch links needed then leave this tab empty.
JobTypes Tab
This tab allows users to define custom job types. These are job types other than the POM-provided ones, namely: EXEC
, RI
, RASE
, BDI
, RPAS
, RDS
, OMS
, and OB
.
These custom job types are associated with the ReSTful endpoints necessary for POM to execute batch. Once defined on this tab, these can then be used in the JobType field on the Job tab.
-
Type – VARCHAR (10)
-
Name of the job type (for example,
RDS
).
-
-
ValidationPath – VARCHAR (4000)
-
ReST Endpoint path for validating that the endpoints for this job type are reachable (for example,
/validation
). -
Can be left blank on this tab but, if so, needs to be provided later on the UI.
-
-
JobStartPath – VARCHAR (4000)
-
ReST Endpoint path to start a job (for example,
/start
). -
Mandatory field if a job type is defined on this tab.
-
-
JobRestartPath – VARCHAR (4000)
-
ReST Endpoint path to restart a failed job (for example,
/restart
). -
Can be left blank on this tab but, if so, needs to be provided later on the UI.
-
-
JobStatusPath – VARCHAR (4000)
-
ReST Endpoint path to check the status of a previously submitted job (for example,
/status
). -
Mandatory field if a job type is defined on this tab.
-
-
JobLogPath – VARCHAR (4000)
-
ReST Endpoint path to fetch log file of a job (for example,
/logs
). -
Can be left blank on this tab but, if so, needs to be provided later on the UI.
-
-
JobKillPath – VARCHAR (4000)
-
ReST Endpoint path to kill a running job.
-
Can be left blank on this tab but, if so, needs to be provided later on the UI.
-
-
OAuthScopes – VARCHAR (4000)
-
Comma-separated list of OAuth scopes for invoking the endpoints.
-
Mandatory field if a job type is defined on this tab.
-
If there are no custom job types in the schedule, then leave this tab empty.