A Batch Schedule Spreadsheet Explained

Overview

This appendix explains all tabs and fields of 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 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.

Guidelines for Updating the Batch Schedule Spreadsheet

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.

  • 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 (for example, different parameters are passed), 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).

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

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

  • Can include arguments as well along with the script.

  For example:

  
  

Process Job Mapping

The Process Job Mapping 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.

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

Example

If a process has 3 jobs in it, then there should be 3 entries in this tab for each job.

ProcessName	JobName	DayOfTheWeek
SAPURGE_PROCESS	SAPURGE_PRE_JOB	Sunday
SAPURGE_PROCESS	SAPURGE_JOB	Tuesday, Wednesday
SAPURGE_PROCESS	SAPURGE_POST_JOB	Thursday, Friday

Dependency Tab

The Dependency tab allows you to define the dependencies between jobs. For each job in a process, you can define the predecessor job and the corresponding process.

• ProcessName – VARCHAR(50)

  • This should match the ProcessName in the ProcessJobMapping tab.

• JobName – VARCHAR(50)

  • This should match the JobName 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.

• PredecessorJobName – VARCHAR(50)

  • This holds the job name in the predecessor process.

Example

ProcessName	JobName	PredecessorProcessName	PredecessorJobName
SAPURGE_PROCESS	SAPURGE_PRE_JOB	SAEXPRMS_PROCESS	SAEXPRMS_POST_JOB
SAPURGE_PROCESS	SAPURGE_JOB	SAPURGE_PROCESS	SAPURGE_PRE_JOB
SAPURGE_PROCESS	SAPURGE_POST_JOB	SAPURGE_PROCESS	SAPURGE_JOB

If an ad hoc process only contains one job, there’s no need to fill up the Dependency tab for such process.

But if an ad hoc process has more than 1 job, the dependencies of jobs 2, 3, and so on need to be defined. There’s no need to define the dependency of the first job, because this will not be dependent on another process/job.

Example

The ad hoc process FCUSTOMERUPLOAD_PROCESS_ADHOC has 2 jobs:

• FCUSTOMERUPLOAD_JOB

• FCUSTOMERPROCESS_JOB

Only the dependency of the second job (FCUSTOMERPROCESS_JOB) needs to be defined:

ProcessName	JobName	PredecessorProcessName	PredecessorJobName
FCUSTOMERUPLOAD_PROCESS_ADHOC	FCUSTOMERPROCESS_JOB	FCUSTOMERUPLOAD_PROCESS_ADHOC	FCUSTOMERUPLOAD_JOB

Recurring Flow Tab

The Recurring Flow tab allows you to define jobs that runs hourly or multiple times a day.

• RecurringFlowName – VARCHAR(50)

  • Uniquely identifies the recurring 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 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.

Recurring Flow Process Tab

The Recurring Flow Process tab allows you to define the processes for each recurring job defined in the Recurring Flow tab.

• RecurringFlowName – VARCHAR(50)

  • This should match the RecurringFlowName in the Recurring Flow tab.

• ProcessName – VARCHAR(50)

  • This holds the process name(s) that are part of the recurring flow. This should match the ProcessName in the Process tab. A recurring 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 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 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

Obsolete Tab

The Obsolete tab allows you to keep track of any process or job that has been deleted from an active environment. Enter the Name and Type of deleted items on this tab.

• Name – VARCHAR

  • Holds the name (for example, Job Name, Process Name, Recurring Flow Name) of the item of type (Job, Process, Flow) being removed from the schedule.

  • For ProcessJobMapping, Dependency / Inter Schedule Dependency/ External Dependency type, it holds the pattern.

  • For ProcessJobMapping type, the pattern should be process#job

  • For dependency type, the pattern should be preJob#preProcess#job#process

  • For InterScheduleDependency type, the pattern should be job#process#externalScheduleName#externalJob#externalProcess

  • For ExternalDependency type, the pattern should be job#process#externalJob

  • For BatchLink (Execution Links) type, the pattern should be job#process#externalScheduleName#externalJob#externalProcess

• Type – VARCHAR

  • Valid values are Process, Job, ProcessJobMapping, Flow, Dependency, InterScheduleDependency, ExternalDependency, BatchLink, Application and Module.

Example

Name	Type
RMSE_MFP_INVENTORY_JOB	Job
RMSE_RDF_DAILY_SALES_PROCESS	Process
DELETE_TAB_STATS_PROCESS#DELETE_TAB_STATS_JOB	ProcessJobMapping
SAIMPTLOGI_POST_JOB#SA_TRANSACTION_LOADING_PROCESS_ADHOC#SAVOUCH_JOB#SA_TRANSACTION_LOADING_PROCESS_ADHOC	Dependency
DELETE_TAB_STATS_JOB#DELETE_TAB_STATS_PROCESS#RDE#RDE_RTLRDEZIP_JOB#RDE_RTLRDEZIP_PROCESS	InterSchedule Dependency
ORBATCH_VERIFY_RCI_JOB#FILE_VALIDATION_PROCESS#EXTERNAL_JOB_NAME	ExternalDependency
DELETE_TAB_STATS_JOB#DELETE_TAB_STATS_PROCESS#RDE#RDE_RTLRDEZIP_JOB#RDE_RTLRDEZIP_PROCESS	BatchLink
RCI	Application
RCICUSTOMER	Module
BDI_PRICING_PC_TX_CYCLE	Flow

System Option Tab

The System Option tab contains the system level options used to control certain aspects of the POM application, such as whether to enable throttling.

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

• Type – VARCHAR

  • Valid values are Process and Job (for example, Job for system option enableThrottling).

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

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)

  • Corresponding Job Admin name (in GBUCS) or Agent name (in CFS) 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.

Example

ScheduleName	Description	Version
Merch	RMS Schedule	21.1.102.0

This tab cannot be empty for any given schedule.

Throttling Configuration Tab

The Throttling Configuration 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.

Inter Schedule Dependency Tab

The Inter Schedule Dependency 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

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

External Dependencies 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

Batch Links 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

If there are no batch links needed then leave this tab empty.

Job Types 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, and RPAS.

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.