1. Implementation Guide
  2. Batch Schedule Spreadsheet Template

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:

  1. In the Process tab, add new processes that end with _POM_VPROCESS. Examples: RMS_SALES_POM_VPROCESS, REIM_EJB_POM_VPROCESS

  2. In the Process tab, set the value in the AdhocInd field to Y because validation processes can only be part of the adhoc cycle.

  3. 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.

  4. 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:

  1. enableOnNew

  2. enableLikePJOnNew

  3. 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 with XXX_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 and BOTH.

    • 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 and N.

    • 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 as N.

    • 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 (under EXPORT_DIFFS_PROCESS) – for the export_diffs.ksh program passing in ‘delta’ as a parameter

      • EXPORT_DIFFS_FULL_JOB (under EXPORT_DIFFS_FULL_PROCESS) – for the same export_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 to SALESPROCESS_PROCESS – for the uploadsales.ksh program run as part of the nightly batch cycle

      • UPLOADSALES_CYCLE_JOB belonging to SALESPROCESS_CYCLE_PROCESS – for the same uploadsales.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 the BATCH_PROCESS_JOB_LIST table. On a schedule upgrade, the ACTIVE_PARAMETER column value is updated with the BASE_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 and N.

    • 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 and N.

    • 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. If N the parameter value won’t be updated for the existing job information.

  • SkipOnError – VARCHAR(1)

    • Valid values are Y and N.

    • 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 are RI, RASE, BDI, RPAS, OMS, OB, RDS, and DUMMY.

    • 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:

      Job Tab
      Job Tab

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 to 9999.

  • 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

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 is 12. For half hourly runs, the maximum value is 24.

  • 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

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 and N.

    • If the process holds the first job of the recurring / adhoc flow, mark as Y. Otherwise, mark as N.

  • LastProcessInd – VARCHAR(1)

    • Valid values are Y and N.

    • If the process holds the last job of the recurring/ adhoc flow, mark as Y. Otherwise, mark as N.

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 of ErrorCode40, 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 and Job (for example, Job for system option enableThrottling or error/warning shell script exit codes or Restartable Error Messages).

    • This defines the JOS admin component the System Option is for. Job is for JosJobAdmin and Process is for BdiProcessFlowAdmin.

  • Description – VARCHAR(255)

    • This holds the value for the System Option. For example, TRUE for system option enableThrottling, 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 the TARGET__BATCH_DURATION. The system options value changes are updated during schedule patching.

      Here's an example SystemOption tab with all the aforementioned system options:

      SystemOption Tab

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, or RI).

  • 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, or RI).

    • 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

    Add System Option Window
    Schedule Tab

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

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

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

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

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.