Batch Best Practices PDF

Batch Best
Practices
Oracle Utilities Application Framework (4.4.0.0.0)
WHITE PAPER / FEBRUARY 2019

DISCLAIMER
The following is intended to outline our general product direction. It is intended for information
purposes only and may not be incorporated into any contract. It is not a commitment to deliver any
material, code, or functionality, and should not be relied upon in making purchasing decisions. The
development, release, and timing of any features or functionality described for Oracle’s products
remains at the sole discretion of Oracle.
2 W HITE PAPER / Batch Best Practices - Oracle Utilities Application Framework (4.4.0.0.0)
Table of Contents
Summary ..................................................................................................... 6
Introduction .................................................................................................. 6
Batch Concepts ........................................................................................... 6
Batch Processing At A Glance..................................................................................................... 6
Batch Program............................................................................................................................. 7
Batch Controls ............................................................................................................................. 8
Batch Parameters .......................................................................................................................11
Multi-Threaded Processes ..........................................................................................................14
Extract Process ..........................................................................................................................16
Batch Architecture ..................................................................................... 16
Batch Technology .......................................................................................................................17
Batch Initiation ............................................................................................................................18
Batch Interface ...........................................................................................................................18
Batch Objects .............................................................................................................................20
Batch Execution..........................................................................................................................20
Configuring Batch Architecture .................................................................. 22
Determining Cluster Configuration..............................................................................................23
Determining Threadpool Configuration .......................................................................................25
Setting Submitter Architecture (optional) ....................................................................................29
Designing Your Threadpool Architecture ....................................................................................31
Implementing Cache Threadpools ..............................................................................................34
Implementing Administration Threadpools .................................................................................36
Administrating Threadpools ........................................................................................................37
Advanced Threadpools using Templates ...................................................................................37
Determining Threads ..................................................................................................................38
Batch Best Practices.................................................................................. 41
Use of Oracle Coherence ...........................................................................................................41
Using the Batch Daemon ............................................................................................................41
Using Timed Batch .....................................................................................................................42
Level 2 Caching in Batch ............................................................................................................44
Level Of Service .........................................................................................................................44
Using Queries to Monitor Batch ..................................................................................................46
Parameter Overrides ..................................................................................................................48
Parameter Guidelines .................................................................................................................50
Setting The Error Tolerance .......................................................................................................50
Altering Commit Interval and Timeout ........................................................................................51
Plug In Batch ............................................................................................. 52
SUMMARY
One of the major channels of the Oracle Utilities Application Framework is

the to execute background processes that process records in bulk. The goal
of optimizing the configuration and operation of this channel is critical to the
success of the implementation.
INTRODUCTION
Typically, a foreground process (a.k.a. online or Web Service transaction), performs operations on a
single instance of an object within the product. Maintaining a person's contact details or processing a
single payment is two such examples. Background processing, by contrast, performs operations on
multiple instances of an object. This coins the term batch where the background process processes
batches of objects. The term background processing implies that the processing is performed in the
background with little or no user interaction.
The product ships with a preset number of background processes that may be used and configured to
perform the necessary business functions for your site. These background processes can be extended
(just like the rest of the product functionality) and custom background processes can be added.
This whitepaper outlines the common and best practices used for the background processing (a.k.a.
batch) component of the Oracle Utilities Application Framework. The advice in this page is based upon
Oracle internal studies and customer feedback around the world. This information is provided to guide
other sites in implementing or maintaining the product in production.
BATCH CONCEPTS
The following section outlines some basic concepts when configuring and executing the batch
component of the Oracle Utilities Application Framework.
Batch Processing At A Glance

A batch program is a program that processes work in bulk to some sort of object for processing and then
completes successfully or fails (due to some error or reaching an error tolerance). Fundamentally, the
batch processing can be summarized as follows:
• Batch Driver. This is a statement that decides the subset (if any) of records to process in the batch
process. The driver can be an SQL statement, or a file read operation to drive the batch process.
Optionally, the subset can support threading natively or rely on the Oracle Utilities Application
Framework to perform this function.
• Process Records. Once the subset of records is determined, something needs to process each
record. This logic can use various objects within the product and/or extract the information to a file (in
the case of a file export batch process). This can be one or more objects to process the records
(typically a single entity that can call other objects) to perform the necessary logic dictated by the
batch process.
• Optionally, perform logic on success or failure. When a batch process completes, it is either
successful or has failed. In some cases, additional logic is required to address this situation.
The batch program relies on the Oracle Utilities Application Framework to provide the infrastructure
around the processing, to reduce complexity and costs, including the following:
• Batch Instance Management. Management of the technical aspects of executing logic in the Batch
Architecture.
• Thread Management. Managing the subdivision of workload if it is not covered in the Batch Driver
and managing the contention across those threads.
• Check Pointing. As batch potentially processes large amounts of data, a check point should be taken
on a regular basis to save progress in case of a major failure.
• Restart Logic. In concert with check pointing, the batch program, in conjunction with the Oracle
Utilities Application Framework, implements logic to start at an appropriate place on restart.
• Interfacing. The Oracle Utilities Application Framework provides the basis for interfacing to objects,
tables and files to hide the technical aspects of the solution regardless of the platform.
• Batch Run Tree Integration. One of the key monitoring and metrics capabilities of the Oracle Utilities
Application Framework is the Batch Run Tree. The Oracle Utilities Application Framework is
responsible for populating the appropriate information in the Batch Run Tree for any execution of a
Batch program.
The processing is summarized below:
Figure 1. Summary of Batch Processing
Batch Program
The main component of the background process is the batch program. This program contains the logic
to select the batch of records that the process will perform actions upon. The batch of records is
progressively passed to the relevant objects to complete processing. The program acts as a driver to
push individual records to the relevant objects. Objects in the product are shared across all modes of
access to maximize reuse.
Apart from the logic to decide the subset of records, the batch program contains the following additional
information:
• The batch program contains the code necessary to interface to the framework to automatically
manage its individual execution and restart (if necessary).
• Some of the batch programs contain the code necessary to multi-thread the processing. The program
determines which slice or subset of the overall data it needs to process. Not all programs support
multi-threading (most do, except the extract to file type processes).
The product ships with a preset number of batch programs associated with background processes that
may be used and configured to perform the necessary business functions for your site. These
background processes can be extended (just like the rest of the product functionality) and custom batch
programs can be added.
Batch Controls
A batch program and its parameters must be defined in metadata prior to initial execution. This data is
stored in a Batch Control object within the meta-data component of the framework.
The Batch Control contains the definition of the batch program and the following additional information:
• Identifier. A Batch Code used as an identifier. This is used by the framework to identify the process
internally and used to denote output.
• Technology. The technology used to build the batch program is configured so that the Oracle Utilities
Application Framework understands which technology to use to initiate and track the process.
• Security. In Oracle Utilities Application Framework V4.3.0.0.0 and above, each batch control can be
controlled via an Application Service to provide additional levels of security.
• Execution Metrics. Basic execution statistics for the last execution, including level of service (if
configured), last execution date and time and the latest run number which is primarily used for extract
processing.
• Fixed Parameters. Each Batch Control has several fixed parameters that control tracing, thread
counts, commit interval and other aspects of behavior.
• Dynamic Parameters. Batch processes can have process specific additional parameters that control
process specific behavior. The batch control defines these as well as default values.
The product ships with a preset number of batch controls associated with background processes that
may be used and configured to perform the necessary business functions for your site. Custom batch
controls can be added as needed.
An example of a Batch Control is shown below:
Figure 2. Sample Batch Control
Batch Run Tree
One of the main features of the Batch Architecture in the Oracle Utilities Application Framework is the
Batch Run Tree. It is an object that collates all the runtime information from the execution of a batch
process and is available from the user interface. The batch run tree captures the following information:
• Batch Execution Metrics. The metrics of start and end times for the process are recorded as well as
some state information at the process level.
Note: The execution start and end times are determined from the longest running thread.
• Thread Metrics. Each thread contains metrics for individual start and end times as well as additional
information such as records processed and in error.
• Exceptions. If there are any exceptions, they are listed in the tree. If they are linked to transactions,
they may be hyperlinked to the record causing the error (process dependent).
Note: Some processes create To Do records to highlight errors within the process or within a companion
process. Refer to the product documentation for clarification.
An example of a Batch Run Tree is below:
Figure 3. Sample Batch Run Tree
It is also possible using the Batch Run Tree to force a complete restart. By default, the Oracle Utilities
Application Framework will restart a process/thread in error at the last checkpoint (As indicated by
Restart Data). To override this behavior and force the checkpoint to be ignored then set Do Not Attempt
Restart on the Run Control Tab. For example:
Figure 4. Sample Restart Override
Note: This functionality only applies to executions in an Error state not completed processes. Setting
this value does not guarantee the process will process the same set of records as originally as the
individual process may ignore already processed records
Batch Parameters
Controlling the behavior of the execution of the batch program are several parameters that are specified
in the Batch Control and on configuration files (depending on the method of execution). These
parameters are technical, and business related and can be explicit or implied. Setting these parameters
can change the run-time and processing behavior of the execution:
Batch Parameters
PARAMETER TYPE SCOPE COMMENTS
Batch Control Explicit Technical/Business This is the identifier of the batch process in
the product. This identifier is used to initiate
the execution and used by some of the
submission methods for logging.
Batch Control Type Explicit Technical This is the type of batch execution used by
the Oracle Utilities Application Framework.
This supports Timed and Non-Timed
process. This is recommended to be set
and not changed.
Batch Category Explicit Business This is used for reporting purposes on

portals and zones and categorizes the
batch control into its relevant business area
Accumulate All Explicit Technical Refer to the online help for an explanation
Instances of this setting.
Thread Count Explicit Technical This is the number of threads to execute for
a multi-threaded process. The minimum is 1
and the maximum is the number of threads
supported concurrently on the architecture.
Refer to Multi-Threaded processes for more
information.
Thread Number Explicit Technical This is the individual thread number to

submit. This is used at submission time to
submit individual threads for
micromanagement and the value must be
less or equal to the Thread Count. Omitting
this value or setting it to 0 will spawn the
number of threads up to the thread count.
Refer to Multi-Threaded processes for more
information.
Override Number of Explicit Technical The number of objects to process before a

Records to Commit commit performed for checkpointing
purposes. If no value is supplied, it is
defaulted within the batch process itself.
Override Maximum Explicit Technical This is the number of minutes the set of
Timeout in Minutes records is processed before a commit is
performed. This prevents sets of data
becoming stale within the database. This
parameter works in conjunction with the
Override Number of Records to Commit to
control checkpoints.
Note: This parameter only applies to legacy
versions of Oracle Utilities Application
Framework that supported COBOL based
extensions. It does not apply for Java or
ConfigTools based batch controls.
Trace Program Start Explicit Technical This setting enables or disables debug
messages to be added to batch logs to
record program start. This is used by
developers to debug their code.
Note: This setting should not be enabled in
Production, unless otherwise instructed by
Oracle Support or your developers
Trace Program Exit Explicit Technical This setting enables or disables debug
record program ending. This is used by
developers to debug their code.
Trace SQL Explicit Technical This setting enables or disables debug

record execution of any SQL statements in
the program. This is used by developers to
debug their code.
Trace Output Explicit Technical This setting enables or disables debug

record outcomes of calls to other objects in
the program. This is used by developers to
debug their code.
Batch Rerun Number Explicit Technical/Business This setting is used at submission time to
rerun specific extracts. In normal operation
this number is not provided. Refer to
Extract processes for a discussion of this
parameter.
Batch Business Date Explicit Technical/Business This is an important submission parameter

that specifies the date (in ISO format
YYYY-MM-DD) that tells the batch program
which records are to be considered for
processing. If not provided, the current
system date is used. It is recommended
that a relevant common date be supplied
for each execution to ensure consistency in
set of records processed.
Batch User Explicit Technical/Business This parameter is required at submission

for use in the batch execution in following
ways:
• Security. The user supplied is checked
within the security system for appropriate
access for the objects used in the batch
program including the Batch Control
itself.
• Ownership. All records created or
modified in the batch process will be
marked with this user in the appropriate
objects. For example, if To Do records
are created then the To Do creator will
be this user.
Email Address Explicit Technical This is an optional parameter used by some

submission methods to send an email
summarizing the result of the process to
this user or group of users (the group must
be setup in the mail system for this to
work).
Note: The use of this facility requires an
appropriate SMTP server to be setup as per
the Installation Guide and Server
Administration Guide.
DIST-THD-POOL Implied Technical This is a hidden parameter in the collection

of parameters to set the threadpool for
execution.
Note: This parameter is only used for
online submission and Oracle Scheduler
Integration. The command line-based
submission should not use this capability.
The command line submission method
uses an alternative way of specifying the
threadpool.
MAX-ERRORS Implied Business This is a hidden parameter which when

used can set the error tolerance for the
process. This sets the number of errors
tolerated before the process is considered a
failure. When this tolerance is reached, the
process is stopped with an error status. By
default, it is omitted which disables the
capability. Refer to Setting the Error
Tolerance for more information.
Multi-Threaded Processes
One of the major features of the batch framework is the ability to support multi-threading. The multi-
threading support allows a site to increase throughput on an individual batch process by splitting the
total workload across multiple individual threads. This means each thread has fine level control over a
segment of the total data volume at any time.
The idea behind the threading is based upon the notion that many hands make light work. Each thread
takes a segment of data in parallel and operates on that smaller set. The object identifier allocation
algorithm built into the product randomly assigns keys to help ensure an even distribution of the numbers
of records across the threads and to minimize resource and lock contention.
In Oracle Utilities Application Framework 4.3.0.4.0 and above, it is possible to separate the logic for
threading using the Process SQL algorithm in Plug In Batch and within the Oracle Utilities SDK built
batch processes.
The capability can be described as follows:
• Thread Limit is Set. A maximum number of Threads is set at execution time to break a large
processing task into smaller parallel tasks. The thread limits need to be set appropriately for the
process as well the architecture. The number of threads specified should not exceed the total number
of threads in all threadpool instances allocated to the batch process. At the execution time this limit
and the name of the threadpool are specified, if the thread limit exceeds the total number of threads
available across all instances of the targeted threadpool then the excess threads will wait till a thread
being available. This will delay the total elapsed time of the process.
• Partitioning Data Sets. Each Thread is allocated a slice or partition of data to process as dictated by
the process. By default, the Process SQL/selection component of the process will allocate roughly the
same number of objects to process. For example, if the thread limit is set to six (6) then each thread
will get approximately 1/6 of the records to process. The best way to visualize the concept of threading
is to use a pie analogy. Imagine the total work set for a batch process is a pie. If you split that pie into
equal sized segments, each segment would represent an individual thread. For example:
Figure 5. Sample Threading
Note: The allocation of records in a thread does not guarantee that the threads will finish at the same
time. If there are some workload skew, some threads will finish later than others.
• Each thread will execute independently. Each thread will work through the individual sets of records
allocated to each thread and finish updating the Batch Run Tree appropriately. When the last thread
of the process is complete then the process is complete.
The concept of threading has advantages and disadvantages:
• Smaller elapsed run-times. Processes that are multi-threaded finish earlier than processes that are
single threaded. With smaller amounts of work to do, processes with threading will finish earlier.
Note: The elapsed runtime of the threads is rarely proportional to the number of threads executed. Even
though contention is minimized, some contention does exist for resources which can adversely affect
run-time.
• Threads can be managed individually. Each thread can be started individually and can also be
restarted individually in case of failure. If you need to rerun thread X then that is the only thread that
needs to be resubmitted.
• Threading can be somewhat dynamic. The number of threads that are run on any instance can be
varied as the thread number and thread limit are parameters passed to the process at run-time. They
can also be configured using the configuration files outlined in the product documentation.
Note: Threading is not dynamic after the process has been submitted.
• Failure due to data issues with threading has reduced impact. As mentioned earlier individual
threads can be restarted in case of failure. This limits the risk to the total process if there is a data
issue with an individual thread or a group of threads.
• Number of threads is not infinite. As with any resource there is a theoretical limit. While the thread
limit can be up to 1000's of threads, the number of threads you can physically execute will be limited
by the CPU and IO resources available to the process at execution time.
Theoretically with the objects identifiers evenly spread across the threads the elapsed run-time for the
threads should all be the same. In other words, when executing in multiple threads theoretically all the
threads should finish at the same time. Whilst this is possible, it is also possible that individual threads
may take longer than other threads for the following reasons:
• Workloads within the threads are not always the same. Whilst each thread is operating on the
roughly the same amounts of objects, the amount of processing for each object is not always the
same. For example, an account may have a more complex rate which requires more processing, or
a meter has a complex amount of configuration to process. If a thread has a higher proportion of
objects with complex processing it will take longer than a thread with simple processing. The amount
of processing is dependent on the configuration of the individual data for the process.
• Data may be skewed. Even though the object identifier generation algorithm attempts to spread the
object identifiers across threads there are some processes that use additional factors to select records
for processing. If any of those factors exhibit any data skew, then certain threads may finish later. For
example, if more accounts are allocated to a part of a schedule then threads in that schedule may
finish later than other threads executed.
Extract Process
A special type of process in the Batch Architecture are extracts of data from the database to a file. These
are considered special as the Batch Run Number pays a clear part of the process. When records are
identified and extracted for processing, the current batch number is attached to those objects (the field
used will vary according to that object) as part of the extraction. This batch number is obtained from the
current batch number on the batch control. To rerun a previously executed extract, if supported by the
process, specify the desired batch number as the Batch Rerun Number.
Note: When using the Configuration Migration Assistant to migrate Batch Controls across environments,
by default the current run number in the target environment is retained and not overridden by the value
from the source.
BATCH ARCHITECTURE
The Batch architecture provided with the Oracle Utilities Application Framework is a flexible and powerful
way of defining and executing batch programs. The architecture has several layers:
• Batch Technology. This layer comprises the technology used to initiate the batch process and/or
manage its relationship with other batch processes. This can range from technology provided with the
Oracle Utilities Application Framework or the provision of third-party technology (in an enterprise
solution). An implementation will use one of the methods supported as their mechanism for managing
and executing batch processes.
• Batch Initiation. This layer describes the different methods of initiating batch processes including
monitoring and managing their progress or restart.
• Batch Interface. This layer is the dedicated interfaces provided to manage and execute batch
processes. This includes providing information to and back to the initiating technology.
• Batch Objects. These are a set of internal objects and functions within the Oracle Utilities Application
Framework to record and manage batch processes.
• Batch Execution. This layer is responsible for executing the batch process as instructed and
providing a mechanism for feedback to the initiating technology as necessary.
The figure below summarizes the above layers as well their components which will be discussed in the
subsequent sections:
Figure 6. Batch Architecture Summary
Batch Technology
In implementing batch architectures, you need technology to initiate and manage individual batch
process or sets of related batch processes (such as in a schedule). In most cases, this is one of the
following technologies:
• Third Party Scheduler. Some enterprises already have invested in an enterprise wide scheduler
that needs to be used to manage all batch processes across the portfolio of products they own via a
set of command line-based scripts. This is typically an enterprise scheduler that provides an ability to
define schedules and groups of batch processes to execute including processes external to the
product. For Oracle Utilities SaaS Cloud implementations, it is possible to use the Scheduler API to
schedule and execute batch processes on your on-premise third-party enterprise schedule to retain
your on-premise investment, if desired.
• Oracle Utilities Cloud Service Foundation (Oracle Utilities SaaS Cloud Only). The Oracle Utilities
Cloud Service Foundation includes a capability to define, manage and execute batch schedules from
the provided interface. This interface uses the Scheduler API to maintain, manage and execute batch
processes and schedules.
• Oracle Enterprise Manager or Oracle SQL Developer. For on-premise or hybrid customers who
want to use the Oracle Scheduler to manage and execute batch processes, it is possible to use the
Oracle Scheduler directly via Oracle Enterprise Manager (Scheduler Central) and/or Oracle SQL
Developer.
• Online Submission (Development/Testing Only). For developers and testers, an online submission
capability, with a dedicated submission screens, is provided to allow for individual batch processes to
be executed. No inter process dependency is supported in this interface. This interface is not
supported on Production systems.
Note: For legacy customers of Oracle Utilities Customer Care And Billing, a basic workflow based
scheduler was provided for development and testing purposes. This interface is not supported for
production use and one of the alternatives outlined above should be used instead.
Batch Initiation
To initiate the execution of batch processes there are three interfaces:
• Command Line Utilities. There are several scripts to submit and management processes including
submission of processes, establishment of a runtime environment for execution and a set of related
configuration files that define the behavior of the batch process and architecture.
• Oracle Scheduler. A set of API's based upon Oracle's DBMS_SCHEDULER capability. This capability
is ideal for most implementations as it is included as part of the base license for all editions of the
Oracle Database, so it tends not to have a license impact. The solution can be implemented locally
or remotely (for an enterprise implementation).
Note: If the DBMS_SCHEDULER objects are placed in a remote database for an enterprise
implementation, ensure that database is licensed appropriately.
• Online Submission. This is reserved for use for developers and testers on non-production
environments and is available via the online of the product.
Batch Interface
Note: For details of all the scripts and API's shown in this section refer to the Server Administration
Guide.
The product provides several flexible interfaces to allow technologies to initiate, manage and monitor
batch processes at the batch control level or the individual thread level.
• Command Line Interface. The Oracle Utilities Application Framework includes a series of scripts
that can be run by an authorized user to configure, manage and execute batch processes. The
following is a summary of the commands available:
Command Line Utilities
UTILITY COMMENTS
bedit.sh This is a utility to create and maintain configuration files relating to the batch
execution architecture. The utility is designed with a wizard like interface to
simplify the building the architecture and reduce common configuration
issues.
jmxbatchclient.sh It is possible to monitor and manage executing batch processes (and threads)
using a JMX interface. This utility provides an interface into the JMX capability
to allow management of executing processes.
starttpw.sh This is a utility to start a group of threadpools from the command line for
schedulers.
submitjob.sh This is the main utility to start or restart execution of a batch process (or
individual thread) and wait for the process (or thread). This interface is used
by third party schedulers to execute individual batch processes.
threadpoolworker.sh This utility can work alone or in tandem with starttpw.sh to start
threadpools individually. This interface is used by third party schedulers to
start or stop individual threadpools.
Note: Refer to the Server Administration Guide for details of the command line options and the execution
of these commands.
Note: As with all commands in the Oracle Utilities Application Framework the splenviron.sh
command MUST be executed prior to any command to set the appropriate environment variables.
• Oracle Scheduler Interface. The OUAF_BATCH package interface is provided so that Oracle
DBMS_SCHEDULER can be used to schedule batch processes.
Note: Refer to the Batch Scheduler Integration for Oracle Utilities Application Framework (Doc Id:
2196486.1) and Server Administration Guide for more information about each API.
OUAF_BATCH Procedures
UTILITY COMMENTS
Submit_process Submits a batch process (or thread) from the scheduler and waits for the
process to complete. This is the main procedure in the API to execute
processes.
Restart_Thread Manually restarts threads for restart. This is used manually rather than from
the scheduler.
Cancel_process Cancels an executing process. This will cancel on the next checkpoint or poll
interval, whichever comes first. This is used by manually to cancel processes.
Set_Option Sets GLOBAL or batch control specific options for the scheduler. This sets
interface specific options and some key parameters.
Unset_Option Unsets GLOBAL or batch control specific options for the scheduler that have
been set by the Set_Option interface.
Raise_Thread_Error This is an internal option which allows for specific thread error processing. It
can be used by the scheduler to force error conditions for testing purposes if
necessary.
• Online Submission. The online submission screen is available for use for testing purposes. This
allows a user to queue an execution of a batch process. Refer to the online documentation for details
of the operation of this screen. An example of the submission is shown below:
Figure 7. Sample Batch Submission
Batch Objects
To support the interfaces a set of objects are provided by the Oracle Utilities Application Framework to
record and manage batch processes. The table below lists the objects used provided for use by the
interface and runtime:
Batch Objects
OBJECT PRIME TABLE USAGE
Batch Control CI_BATCH_CTRL Batch Controls that define the batch process to the
Oracle Utilities Application Framework
Batch Job CI_BATCH_JOB Submission initiation object used by Online

Submission and Oracle Scheduler Interface. This is
not used by the command line interface.
Batch Run CI_BATCH_RUN This is the working object used for initiation,
execution and monitoring by the Oracle Utilities
Application Framework batch architecture. It is used
by the execution capability as well as the basis for
information in the Batch Run Tree. An object per
execution is persisted in this object along with related
information in child objects.
These objects are manipulated by the execution engine as well as the submission methods shown
above. These objects are not to be manipulated manually under any circumstances.
Batch Execution
The key component of the batch architecture is the execution architecture to execute multiple threads
of multiple batch processes effectively. The architecture is based upon the following principles:
• Coherence Based. The architecture is based upon clustering batch resources using the Named
Cache capability within the Oracle Coherence product. Oracle Coherence provides the ability to
cluster resources across machines and effectively scale vertically as well as horizontally needed for
performing batch effectively and efficiently.
Note: A restricted use license of Oracle Coherence is provided with the Oracle Utilities Application
Framework for the exclusive use as the runtime for the batch architecture. The libraries provided with
the Oracle Utilities Application Framework are not a full installation of Oracle Coherence and the license
does not allow usage outside the runtime of the batch architecture. If the additional use is needed for
Oracle Coherence an additional license needs to be purchased. Use of the Management Pack for Oracle
Coherence for Oracle Enterprise Manager or Java VisualVM Coherence Plugin is not recommended to
be used with the batch architecture as the installation provides a limited set of libraries which are not
compatible with the Management Pack for Oracle Coherence.
• Flexibility in architecture. The architecture supports simple and complex architectures across single
or multiple machines using a variety of networking methods.
• Robust. The architecture detects issues in execution and keeps the Oracle Utilities Application
Framework appropriately informed in real time and as the process completes to ensure consistency.
• In built batch daemon. For the online submission and Batch Scheduler integration a daemon is
available in the architecture to detect the initiation of activities. This daemon detects pending requests
and submits them to the architecture.
The batch architecture is based upon the following concepts:
• Threadpools. Long running Java Virtual Machines (JVM's) are waiting for threads to process. These
are known as threadpools. These are the JVM's that perform the work.
– Clustered Threadpools. Each threadpool is named (for individual or groups of JVMs). This allows
clusters of similar named threadpools to form a larger virtual threadpool to allow for greater numbers
of concurrent threads.
– Thread Limits on Threadpools. Each threadpool has and have individual thread limits to avoid
JVM overload. The thread limits on similarly named threadpools accumulate to support greater
numbers of concurrent threads.
• Configurable Threadpool Behavior. The configuration of threadpools allows for JVM behavior,
caching and node management within a cluster to be configured.
• Submitters. When a Batch Interface requests to execute a batch process or thread a submitter is
created within the cluster to act as the client to the cluster. The submitter tells the cluster what to run
and where and then waits around for the threads to finish.
• Batch Daemon. A running batch daemon that looks for pending work to submit to the cluster. This is
used exclusively with the Batch Scheduler Integration and Online Submission methods.
These execution concepts are shown below:
Figure 8. Batch Execution Architectures
CONFIGURING BATCH ARCHITECTURE

One of the first tasks to consider in the batch architecture is the composition of the architecture in terms
of the cluster and the resulting threadpools. It is highly recommended to use the bedit.sh utility to perform
this task to reduce errors. To use this facility, ensure that the Enable Batch Edit Functionality is set to to
true using the configureEnv.sh -a command. For example:
$ configureEnv.sh -a
*************************************************
* Environment Configuration demo *
*************************************************
50. Advanced Environment Miscellaneous Configuration

...
Enable Batch Edit Functionality: true
...
To confirm this setting check for the BATCHEDIT_ENABLED setting in the

$SPLEBASE/etc.ENVIRON.INI file:
$ cat $SPLEBASE/etc/ENVIRON.INI | grep BATCHEDIT
BATCHEDIT_ENABLED=true
Once enabled the following commands can be used to set up the architecture:
Command Options
COMMAND USAGE REFERENCES
bedit.sh -c <options> Sets up the cluster configuration • Cluster Architecture

including networking
bedit.sh -w <options> Sets up threadpool definitions • Threadpool Architecture

across the cluster • Cache Threadpools
• Administration Threadpools
bedit.sh -s <options> Sets up submitter definitions • Submitter Architecture

(optional)
bedit.sh <filename> Edit the configuration file name Refer to each section on the file
directly. This file must be generated names that are generated by
by bedit.sh to be edited by that bedit.sh.
utility.
Note: Use the bedit.sh -h command for a full list of options available
Note: Refer to the Server Administration Guide shipped with your product for details of the bedit.sh
utility and how to use its facilities.
Determining Cluster Configuration

The first step in a batch architecture is to decide the cluster architecture and networking used for cluster
communication. This configuration is used by Oracle Coherence Clustering to define the
communications across the batch architecture which creates a tangosol-coherence-
override.xml configuration file located in the $SPLEBASE/splapp/standalone/config
directory.
Note: If the online includes the daemon or batch server, then changes to this file will need to be included
in the build of the online deployment files and a redeployment is required to update the deployment files.
Note: If you are using the bedit.sh functionality, do not manually edit the generated configuration files
as this may cause the utility to overwrite manual changes.
The product supports several cluster types using the command:
$ bedit.sh -c -t <template>
The cluster types support are as follows:
Cluster Types
CLUSTER TYPE (TEMPLATE) USE CASES COMMENTS
Single Server (ss) The cluster is restricted to the This is useful for non-production
current host. environments with the simplest
networking using Single Host
Protocol
Uni-cast (wka) The cluster uses unicast protocol This is recommended for sites
with the hosts explicitly named wanting to lock down a cluster to
within the cluster that are part of the specific hosts and does not want
cluster. to use multi-cast protocols.
Administrators will have to name
the list of hosts, known as Well
Known Addresses, that are part
of the cluster as part of this
configuration
Multi-cast (mc) The cluster uses the multi-cast This is recommended for sites
protocol with a valid multi-cast IP who want a dynamic
address and port. configuration where threadpools
and submitters are accepted on
demand. This is the lowest
amount of configuration for
product clusters as the
threadpools can join a cluster
from any server with the right
configuration dynamically. It is not
recommended for sites that do
not use the multi-cast protocol.
When using these configurations, the following advice should be considered:
• Ensure the Cluster Name is unique per environment. A cluster name is a user-defined name that
uniquely identifies a cluster from other clusters that run on the network. When building batch cluster
definitions ensure each environment has their own unique cluster name and ports to avoid conflicts
and incorrect networking.
• Use Single Server for Non-Production. To save costs and risks, it is recommended to use Single
Server Clustering in all non-production environments. The only exception is when you are using a
non-production environment with multiple hosts.
• Use Multi-cast if possible. If your site can use multi-cast, use that setup in preference to uni-cast to
reduce maintenance costs. Multi-cast implementations are more dynamic and reduce the amount of
configuration.
• Ensure all WKA's are defined in Uni-cast. Ensure all your hosts and associated ports are defined
in your uni-cast cluster configuration. Ensure each of those hosts has the same configuration. Hosts
and their associated ports will not be able to use the cluster if they are not defined explicitly.
Note: You may need to alter the configuration per host to ensure that the configuration is valid.
• Use the same port per machine in WKA. The uni-cast configuration uses host names and port
number combinations to define the cluster. Avoid different port numbers on individual machines to
reduce maintenance complexity.
• Avoid using prod mode in non-Production. The cluster may be configured to operate in either dev
(development) or prod (production mode). These modes do not limit access to features, but instead
alter some default configuration settings. For instance, development mode allows for faster cluster
startup to ease the development process. It is recommended to use the development mode for all pre-
production activities, such as development and testing. This is an important safety feature, because
the cluster configuration automatically prevents these nodes from joining a production cluster. The
production mode must be explicitly specified when using the cluster in a production environment.
Note: Oracle Utilities Application Framework has additional built-in membership validation to prevent
unintentional non-production nodes joining production, regardless of the mode setting.
The figure below summarizes the type of information to configure for each template:
Figure 9. Cluster Configuration
The cluster is created, operationally, when the first threadpool is started. Conversely a cluster is closed
when the no threadpools are executing for that cluster. No additional operations are needed explicitly to
start or stop a cluster.
Determining Threadpool Configuration

After the cluster is configured the next important step is to design and configure the threadpools needed
for the architecture. Before discussing advice on design, several concepts need to be understood:
• Threadpools are Java Virtual Machines. Each instance of a threadpool is a separate Java Virtual
Machine which consumes memory and CPU, even when idle and waiting for work.
• Batch Threads are long running and use more resources than usual threads. Individual Java
Virtual Machines can potentially process hundreds of threads in normal operation. Batch threads are
long running and tend to use far more resources per Java thread that normal threads, which tend to
be more transient and shorter lived. Therefore, the number of batch threads that each Java Virtual
Machine can handle is greatly reduced. By default, the number of batch threads can be as small as
five (5) which means more than one threadpool instance may be needed to cover all threads.
• Threadpool Instances have a flexible architecture. A cluster of threadpool instances can exist
within a single host or across hosts and multiple instances of the same named threadpool can exist
within the same machine or across machine. The figure below illustrates some of the most common
configuration scenarios.
The figure below illustrates a set of example configurations:
Figure 10. Example Scenarios
In the above example, there are two hosts (host1 and host2) with mixed number of thread pools with
unique names:
Example Threadpool Setup
THREADPOOL COMMENTS
POOL1 This represents the simplest scenario (A) with a single threadpool instance on a single
host. The number of threads is limited by the limit on the individual instance.
POOL2 This represents a scenario (B) where multiple instances of the same named threadpool
exist on a single machine. The number of threads available in that named pool is the
sum of the instances.
POOL3 This represents a scenario (C) where multiple instances across machines. This is like
the scenario with POOL2 in that the number of threads available in that named pool is
the sum of the instances but illustrates that the pool is not constrained within machines.
Note: The scenarios shown above are not exhaustive as variations within each of the scenarios having
the ability to be combined to enable support for complex scenarios. For example, the scenarios of POOL2
and POOL3 (B and C) can be combined if necessary.
To setup threadpools use one of the following commands:
$ bedit.sh -w
$ bedit.sh -l <arg>
There are two commands to create threadpool definitions:
• Default option (w). This is the first option used to create a generic set of threadpools. This generates
a threadpool.properties file used by the threadpoolworker.sh script.
• Using Templates (l). This will be examined in Advanced Threadpools using Templates. This
generates a template specific threadpool.properties file that can be used by the
threadpoolworker.sh script.
Figure 11. Threadpool Configuration
The following applies when configuring the threadpools:
• Java Virtual Machine settings are within the template. The memory settings for the JVM are at the
template level not at the threadpool level. Unless otherwise stated, the default settings are enough for
most needs.
• There are several thread related settings. Threads are used internally to manage the cluster and
within the threadpool to execute the work.
Thread Settings
SETTING OUAF SETTING COMMENTS
distthds tangosol.coherence.distributed.threads This setting controls the number of

internal daemon threads allocated
to Oracle Coherence to manage the
members in the cluster for the
Distributed Cache Service. If this
value is set to 0, then this will force
Coherence to use its service thread
to perform all relevant tasks, which
can cause issues in the Oracle
Utilities Application Framework. It is
recommended to set this value to
the default provided in the
templates, unless otherwise
instructed by Oracle Support.
invocthds tangosol.coherence.invocation.threads This setting controls the number of

internal daemon threads allocated
to Oracle Coherence to manage the
execution of members in the cluster
for the Invocation Service. If this
value is set to 0, then this will force
Coherence to use its service thread
to perform all relevant tasks, which
can cause issues in the Oracle
Utilities Application Framework. It is
recommended to set this value to
the default provided in the
templates, unless otherwise
instructed by Oracle Support.
threads com.splwg.grid.distThreadPool.threads. This is a setting provided by the

<threadpoolname> Oracle Utilities Application
Framework to set the number of
concurrent batch threads are
allocated to each instance of a
named threadpool. These are the
long running heavy threads
performing the work. Advice on this
setting will be later in this section.
• Other Settings. There are several settings in threadpools that should be considered when configuring
the threadpools:
Thread Settings
SETTING OUAF SETTING COMMENTS
dkidisabled spl.runtime.batch.disableDeferre This is a setting that controls the use of

dKeyInserts Deferred Key Insert logic that are
needed in some Oracle Utilities
Application Framework. Refer to the
product documentation to see if this
capability is required.
rmiport spl.runtime.management.rmi.port Port used for JMX communication for

monitoring purposes. This port is used
for cluster wide monitoring from the
Oracle Utilities Application Framework,
Oracle Utilities Cloud Service
Foundation and the Application
Management Pack for Oracle Utilities.
This setting is overridden by the
jmxstartport parameter at runtime.
storage tangosol.coherence.distributed.l This enables or disabled local storage

ocalstorage in the cache. Depending on the
architecture the value of this parameter
will vary. For a full discussion refer to
Implementing Cache Threadpools and
Implementing Administration
Threadpools. At least one threadpool
per cluster must have this set to true.
daemon com.splwg.batch.scheduler.daemon This disables or enables the inbuilt

processing daemon. This is set to true
for environments using online
submission or the Oracle Scheduler
integration. Sites using the command
line submission method from a third-
party scheduler should set this to false.
Refer to Using the Batch Daemon for
further advice.
role tangosol.coherence.role This is a generic tag used for

monitoring purposes only. This allows
groups of threadpools to be defined for
monitoring purposes.
jmxstartport oracle.ouaf.jmx.remote.startPort This is a newer JMX port number

parameter which dynamically sets the
port number based upon availability of
a port. This setting is ideal for
implementations that have multiple
threadpools on the same host. Each
threadpool will have its own port from
this port. Set the value the same as the
rmiport parameter.
l2 spl.runtime.batch.L2CacheMode The batch architecture can use level 2

caching to improve performance. This
setting controls the caching with various
setting. Refer to Level 2 Caching in
Batch for additional advice.
devmode spl.runtime.options.isDevelopmen This setting is used for Development

tMode environments (using Oracle Utilities
SDK) to turn off advanced features to
allow developers to perform unit testing
appropriately. This is recommended to
be set to true for Oracle Utilities SDK
environments only.
• Threadpool Collection. Create a collection of threadpools to suit your needs. For each threadpool
specify a threadpool name and thread limit per instance of that threadpool. Refer to Designing Your
Threadpool Architecture for detailed design advice.
Note: Remember to save any changes at the end of the session to create the configuration files.
Setting Submitter Architecture (optional)

Note: Customers using the online submission and Batch Scheduler integration should not generate
configurations for submitters as they use a combination of the Batch Control and command line overrides
to process submitters.
Note: At present, there is no product supplied utility to automatically generate the parameter files from
the Batch Control.
The final step in the batch architecture is to build and maintain a configuration file (if required) for
individual batch controls which are used by the submitjob.sh utility.
To setup submitters use one of the following commands:
$ bedit.sh -s
$ bedit.sh -b <batch_control>
There are two commands to create submitter definitions:
• Default option (-s). This sets up a default configuration file used for any batch control where no
specific batch properties file exists. This creates a submitbatch.properties file located in the
$SPLEBASE/splapp/standalone/config subdirectory.
• Batch Control Specific configuration (-b). This will create a batch control specific configuration file
named job.<batchcontrol>.properties where <batchcontrol> is the Batch Control
identifier. This file is in the $SPLEBASE/splapp/standalone/config/cm subdirectory. In this
option, the soft parameters on the batch control can be configured as well.
Note: The Batch control identifier used in the -b option should be in the same case as the Batch Control
record in the Oracle Utilities Application Framework.
Figure 12. Submitter Configuration
When using these commands, it is recommended to:
• Use the -s option where possible. Setup a global configuration to cover as many processes as
possible and then create specific process parameter files for batch controls that require soft
parameters.
• Minimize the use command Line overrides. The advantage of setting up submitter configuration
files is to reduce your maintenance costs. Whilst it is possible to use command line overrides to
replace all the settings in the configuration, avoid overuse of overrides to stabilize your configuration.
• Set common batch parameters. Using the -s option allows for the following common parameters
to be setup:
Common Submitter Settings
SETTING COMMENTS
poolname This is the default threadpool used for the batch execution if none is specified on the
command line or in a process specific configuration. This should be set to an appropriate
threadpool.
threads This is the number of concurrent threads that are executed when no thread limit is
specified on the command line or in a process specific configuration. It is recommended
to set this to 1 to prevent unnecessary overloading of threadpools.
commit This is the default commit interval (in object counts) if no commit interval is specified on
the command line or in a process specific configuration.
maxtimeout This is the timeout limit (in minutes) for holding the set of records processed. This is a
legacy setting for older versions of the Oracle Utilities Application Framework that
supported COBOL extensions to prevent stale record sets.
user This is the default application user used for security purposes if no user is specified on the
command line or in a process specific configuration.
Note: The default SYSUSER account should NOT be used for this setting. The AUSER
setting suggested in the template, needs to be changed to an appropriate value. It is
intentionally invalid to force a change in the configuration.
lang This the default language code used for messages used in this execution if no language
is specified on the command line or in a process specific configuration.
storage This is the default for configuration storage within the cluster. This setting should be set to
false unless otherwise instructed in the product documentation.
role This is a tag used for monitoring purposes. By default, the batch code used at runtime is
used to set this value.
• Setup soft parameters in process specific configurations. For batch controls that have
parameters, these need to be set in the configuration file or as overrides on the command line. To
minimize maintenance costs and avoid potential command line issues, it is recommended to set the
values in a process specific configuration file, using the add soft command in bedit.sh with the
following recommendations:
– The parameter name in the parm setting must match the name and case of the Parameter Name
on the Batch Control.
– The value set in the value setting must be the same or valid for the Parameter Value on the Batch
Control.
– Optional parameters do not not need to be specified unless used.
Note: Do not add a parameter for the DIST-THD-POOL soft parameter as that is configured via the
poolname parameter.
Designing Your Threadpool Architecture

One of the most important aspects of the architecture is to decide and design the threadpools you need
to create for your implementation. There are two important aspects to consider:
• Naming Threadpools. The key feature of the architecture is to name threadpools and use that name
to target batch processes to. The only limit for the threapools is the number of instances supported
on a machine as the physical memory allocated to a machine will dictate the number of JVM's
supported on a host.
Note: Remember each threadool instance is a running JVM with memory requirements (by default,
each instance consumes 1GB of memory - This is customizable).
• Thread Limits per Instance. Each threadpool instances supports a certain number of long running
threads threads set up to the limit.
The table below outlines common threadpool architecture patterns:
Common Threadpool Patterns
PATTERN SUMMARY COMMENTS
Single Named Create a single threadpool name (such as This is the simplest architecture and
Threadpool DEFAULT) and then use that to run ALL tends to be used for non-Production
processes within the architecture using environments where you start with a
instances of that threadpool . The number of single threadpool instance either
instances of this threadpool will dictate the standalone or within the online JVM
number of concurrent threads supported. (the latter scenario is used for
demonstrations and training).
Dual Threadpools Create two threadpools (one with L2 caching This is a variation on the Single
on and one with L2 caching off). There are Name Threadpool with an additional
internal processes, such as Configuration named threadpool for L2 Caching on
Migration Assistant and LDAP for the small number of processes
Synchronization, that benefit from the Level 2 that require it. Most sites restrict
cache being turned off. Treat the L2 Cache themselves to a single L2 Cache Off
On threadpool the same way you would treat instance per cluster with enough
Single Named Threadpool capacity to cater for the small number
of processes that require it.
Note: The threadpool with L2 Cache
Off only needs to be available when
needed by these processes.
For more guidelines around Level 2
Caching refer to Level 2 Caching in
Batch.
Targetted This is a wide set of variations where you set This is varied with the following
Threadpools up several named threadpools with specific considerations:
global settings optimized for use with specific • Keep Default Configuration.
processes and some for generic processes. Setup a generic default pool for
non-specific processes. For
example, small processes or single
threaded processes can be
targetted to this default setup.
• Specific Java Configuration. For
processes that require special java
setups that are not covered by the
default, consider setting up specific
threadpools which are configured
for processing.
• Consider Segregating Critical
Processes. While sharing
threadpools across processes is
efficient, some sites have
considered setting up a specialist
set of critical threadpools to isolate
and optimize those processes
accordingly. For example, it is
easier to scale those specialist
threadpools in isolation to other
processes. This is more
micromanagement but allows
implementations to manage and
target their resources appropriately
for their business needs.
The following figure summarizes some typical patterns:
Figure 13. Submitter Configuration
The decision on which patterns are best suited for you:
• Use Single Threadpool or Dual Threadpools for non-production. Keep your maintenance costs
low and setup your non-production using the simplest architectures.
• Threadpools Only need to be available when needed. One common misconception about
threadpools is that they need to stay running all the time. Whilst it is possible to keep them running all
the time, they only need to be available when the processes that use them require them. Most sites
shut down threadpools when they are not being actively used to reduce wastage of resources.
• If using Single Threadpool pattern, use the online threadpool. For demonstrations, it is
recommended to keep the installation simple. In this case, the online can run some batch threads for
demonstration and training purposes. Refer to the Installation Guide for details of how to enable this
functionality.
• Flexible Production Setup. In production, a more complex architecture it required to satisfy the
needs of the batch processes to execute. When designing the production batch architecture consider
any of the following patterns:
– If JVM requires additional parameters, consider a separate template. JVM settings are at the
template level, use the bedit.sh -l <template> command to create a new template with the
settings. Within that template specify your settings. Refer to Advanced Threadpools using
Templates for more information.
– Create Dedicated Threadpools for critical processes. One technique that is popular is to create
a threadpool or a group of threadpools for critical processes. This allows these threadpools to scale
independently and allows processes using the threadpool to be isolated from other processes. If
you do not have a dedicated threadpool available, then there is a risk that any other process
executing at the same time will prevent efficient execution of the critical processes.
– Create L2 Cache Threadpools for utilities. As in production the use of certain utilities will be
necessary from time to time (for example using Configuration Migration Assistant) then a threadpool
with L2 Caching disabled is recommended to be available whenever these processes are executed.
Refer to Level 2 Caching in Batch for more discussion.
– Create Cache Threadpools. If the number of instances is high, it is recommended to consider

using cache threadpools. These threadpools will reduce the amount of communication in the cluster
for many threadpools. Refer to the Implementing Cache Threadpools for more advice.
– Create an Administration Threadpool (if desired). If you are actively monitoring the execution of
processes using JMX directly or via the Application Management Pack for Oracle Utilities, it is
recommended that you consider specifying a threadpool instance for strictly administration
purposes. Refer to Implementing Administration Threadpools for more advice.
Implementing Cache Threadpools

When implementing many threadpools in the cluster, the architecture establishes communications
between each of the threadpools across a cluster to determine state and workload. If there are n
threadpool instances, then there are n * (n -1) connections in the cluster. As the number of threadpool
instances increases this potentially increases network overhead on the cluster. To alleviate this issue, it
is recommended to implement the concept of a cache threadpool. This special type of threadpool does
not run any threads but centralizes the communication across the threadpool instances on that host.
This reduces internal traffic between any threadpool instances on that host. For example:
Figure 14. Cache Threadpools
The concept is implemented using the local-storage option in Oracle Coherence. The threadpools
are configured so that the local-storage is disabled and, on the cache threadpool it is enabled. This
tells Oracle Coherence to distribute the state of any process to the cache threadpool to save networking.
If the cache threadpool is active the cluster will use that threadpool to centralize communications.
Note: When committing to use cache threadpools you MUST configure the threadpools that use the
cache to storage set to false.
To setup the cache threadpools use the recommended command:
$ bedit.sh -l cache
File
/u01/demo/splapp/standalone/config/cm/threadpoolworker.cache.properties
does not exist. Create? (y/n) y
Editing file
/u01/demo/splapp/standalone/config/cm/threadpoolworker.cache.properties
using template /u01/demo/etc/threadpoolworker.cache.be
Batch Configuration Editor [threadpoolworker.cache.properties]

--------------------------------------------------------------------------
Current Settings
poolname (cache)
minheap (768m)
maxheap (768m)
distthds (4)
invocthds (4)
role (OUAF_Cache_TPW)
jmxstartport (7540)
>
• Edit the settings to suit your needs.
The product ships with a prebuilt cache template named threadpoolworker.cache.be.
Implementing Administration Threadpools

Note: Use of Administration Threadpools is only recommended for sites wanting to monitor batch in real
time via JMX or via the Application Management Pack for Oracle Utilities. Customers on the Oracle
Utilities SaaS Cloud will have an Administration threadpool for use with Oracle Utilities Cloud Service
Foundation.
By default, every active threadpool instance provides a JMX interface for monitoring purposes using
different port numbers for interaction. If you want to monitor the cluster in real time using JMX directly
or via the Application Management Pack for Oracle Utilities, then you need a fixed port and address to
connect to the cluster each time. In these situations, it is recommended, in complex production
environment, to setup a dedicated Administration threadpool. An Administration threadpool is similar in
nature to a cache threadpool in that it does not run batch threads and is only available to act as a conduit
into the cluster for the JMX interface.
Note: To use the Administration threadpool ensure it is the first threadpool to start to reserve the JMX
port number appropriately.
Note: There is no Administration threadpool template shipped with the product. Use the default template
to create the administration threadpool.
To create the Administration threadpool use the command:
$ bedit.sh -l admin
Batch Configuration Editor [threadpoolworker.admin.properties]

--------------------------------------------------------------------------
Current Settings
minheap (768m)
maxheap (768m)
daemon (false)
rmiport (7540)
dkidisabled (false)
storage (true)
distthds (4)
invocthds (4)
role (OUAF_Admin_TPW)
jmxstartport (7540)
l2 (OFF)
devmode (false)
ollogdir (/u02/sploutput/demo)
ollogretain ()
thdlogretain ()
timed_thdlog_dis (false)
pool.1
poolname (ADMIN)
threads (1)
>
Note: The above settings are suggestions for the threadpool using the appropriate set command within
bedit.sh.
Administrating Threadpools
Now that the threadpools are created the next step is to start and stop them using the
threadpoolworker.sh command on the hosts you want to run the threadpools:
$ threadpoolworker.sh -l <template> [-p <threadpool>]
Where:
<template> Configuration file to use threadpoolworker.<template>.properties
<threadpool> Threadpool within template to start. Omitting this will start an instance of all
threadpools in the file.
Note: Use the UNIX kill command or use the jmxbatchclient.sh interface to stop the instances.
Refer to the Server Administration Guide for more details.
Note: Run the command more than once to create multiple instances of threadpools on a host. Ensure
you have enough memory to run the total number of instances running at any time.
Advanced Threadpools using Templates

The product ships with several templates that can be used to build threadpool definition using
bedit.sh. These templates exist in the $SPLEBASE/etc directory of the installation:
Threadpool Templates
TEMPLATE TEMPLATE NAME COMMENTS
Default threadpoolworker.be Used for default settings and administration

threadpools. This is the main configuration file.
Cache threadpoolworker.cache.be Used for cache threadpools only
Job threadpoolworker.job.be Used as a basis for any custom threadpools or

specialist threadpools (use the bedit.sh -l job
command to use this template)
it is recommended to use the templates as follows:
• Use Default Template for Most Threadpools. Use the default template for non-product threadpools
and use for any general purpose threadpools in your architecture. Keep the defaults unless they are
not appropriate for your requirements.
• Use Cache for a cache threadpool per host. For complex setups with lots of threadpools, create a
cache threadpool using this template. Avoid this for non-production to save on maintenance costs.
• Use the Job Template for Specialist Threadpools. If you need to alter the threadpools for
specialization
If a template does not exist for use in the -l option, then the default template will be used as a template,
but the configuration is stored in its own configuration file. Refer to the Implementing Administration
Threadpools for an example of this.
Determining Threads
One of the most important decisions to make on a day to day basis is to determine the number of threads
to run for an individual process. Before discussing the threading recommendations a few concepts need
to be reinforced:
• Thread Limit is Set At Submission Time. When you execute any process, using any submission
method, one of the parameters is the thread limit. This is the fixed limit set at submission time and
cannot be altered, even for a restart, after the process has started.
• Individual Threads can be submitted. Even though most submissions will submit all the threads, it
is also possible to submit individual threads using the various submission methods. This allows sites
to micromanage threads from schedulers or support advanced threading models (for example,
submitted different threads to different threadpools).
• Thread numbers are cumulative across named instances. When you submit a process, using any
submission method, the threadpool name is also a parameter. This is the set of threadpool instances
that will execute the threads of the batch process. The number of threads available for the process is
the total cumulative number of threads of active instances of that named threadpool. For example, if
you have one instance and it was 5 threads then the total is 5, if you have two instances of 5 threads
the total is now 10 etc. For instance:
Figure 15. Cumulation Of Threads
• Respect Availability Of Threads. When a batch process is submitted to a threadpool, the total
number of threads in all running instances should be the same or more than the thread limit for all
processes submitted at that time to that threadpool. If there are not enough available threads across
the instances some threads will wait and be delayed from execution. This will delay the overall
execution of the process. In the example below, the first execution is within the thread limit ( 4 < 5 ),
the second execution is not within the limit ( 6 > 5 ) and therefore a threads waits for any other thread
to complete before starting. The last example, shows that with two running instances of the threadpool
that there is enough capacity ( 6 < 10 ):
Figure 16. Thread Scenarios
• Shared Threadpools Need Careful Planning. If more than one process is executing at the same
time in the same named threadpool, then there needs to enough capacity across all executions at any
time. For example, if two processes are executing at the same time and both have 3 threads each
and the threadpool has a capacity of 5 then a thread will wait ( 6 > 5 ):
Figure 17. Thread Scenarios
• Consider Metrics. The number of objects processed per minute/second and the elapsed time are
key metrics to use for planning purposes. The number of objects processed per minute/second are
determined by calculating the total minutes or seconds in the elapsed time per thread and dividing the
number of records processed to determine the rate of processing. For error prone processes, also
consider the number of errors as well.
Now these concepts are understood let us discuss the determination of threads:
• Extracts and Imports are Single Threaded. Before you consider any threading, any exports and
imports are only single threads, so the thread limit should always be set to 1. This helps ensure the
correct processing of the import and export files involved in these processes.
Note: No attempt should be made to run single threaded processes in a multi-threaded mode as this
may make the process fail or cause inconsistencies. Refer to the product documentation for guidelines
on individual processes (or review the description on the batch control).
• Some Processes are Single Threaded. Review the product documentation for thread guidelines for
each product process.
• Do Not Overload Your Threadpools. It is tempting to flood the threadpools with large number of
threads, but it is recommended not to overload the threadpools with large number of threads.
Increasing number of threads can resolve data skew and reduce elapsed time but can introduce
inefficiencies due to contention. The rule of thumb is to increase the number of threads, monitoring
the number of objects processed per second/minute till this value decreases. That would be the
natural limit of your configuration to the threading.
• Only Increase Threading When Needed. It is tempting to change the thread limits on the processes
on a regular basis but stick to a limit and only change it when the number of objects processed per
second/minute or level of service is not reached.
• Threadpool Limits are Configurable. The default in the configuration is 5 batch threads per instance
of a threadpool. This number was chosen to represent the heaviest processes in the product. It can
be increased for lighter processes.
• Start Simple and Adapt. In your testing, determine a good starting point for the number of threads
to submit for any multi-threaded process. Monitoring the elapsed and number of objects processed
per minute/second should determine if you need to increase or decrease that number.
• Consider Special Cases. In most implementations the data processed each execution of a process
might yield the same elapsed time overall but if the business has a special event that changes the
amount to process then the amount of threads for the duration of that event may need to increase or
decrease. For example, if you are expecting double the volume then you might need to increase the
number of threads accordingly.
BATCH BEST PRACTICES

The batch architecture is both flexible and powerful so configuring, managing and operating batch is
important to the success of an implementation. There are techniques and practices that help ensure
success.
Use of Oracle Coherence

As part of the batch architecture, key Oracle Coherence libraries are shipped with the product to create
a cluster at runtime to house submitter and threadpools. The libraries are part of a Restricted Use
License provided with the Oracle Utilities Application Framework with the following conditions:
• Limited Implementation of Coherence. The libraries shipped are a subset of the Oracle Coherence
stack and implement the Distributed Cache and Named Cache functionality only. As the provided
libraries represent a subset only, it is not recommended to use the Oracle Coherence Pack available
for Oracle Enterprise Manager with the cache or cluster as that will yield inconsistent results.
• Restricted Use. The libraries are provided using a Restricted Use License for exclusive use with the
runtime of the batch architecture and cannot be used in any extensions to extend the product
(including any batch processes).
• Patching. The Oracle Coherence libraries shipped with the Oracle Utilities Application Framework
and are patched with that product. Unless otherwise directed by Oracle Support, do not manually
manipulate the versions of the libraries as this may cause inconsistencies in execution.
Using the Batch Daemon

Note: Customers using the command line submission method (via the submitjob.sh utility) should
not enable the daemon as it is not used by that submission methods.
For the online submission and Oracle Scheduler Integration at least one threadpool must have the
daemon running. This daemon looks for pending work that has been submitted by these methods and
submits it to the cluster on behalf of the user. To use the daemon there are two places to set the value:
Daemon Settings By Submission Method
SUBMISSION METHOD SETTING
Online Submission (non- The following setting should be set to true using the configureEnv.sh -a
Production use only) command:
configureEnv ENVIRON.INI Value Comment
Setting Setting
Online JVM BATCHDAEMON true
Batch
Scheduler
Daemon
Enabled
Online JVM BATCHENABLED true Only set this value if
Batch Server you want the online
Enabled JVM to include the
threadpool. This is
recommended for
demonstration
environments.
Batch Scheduler Integration In the default threadpool template, using the bedit.sh -w command,
ensure that the daemon setting is set to true. For example:
...
daemon (true)
...
The daemon should exist in at least one threadpool in the architecture and once active will actively look
for jobs that are in pending status (with other appropriate attributes) and submits them to the
architecture. Once the job has completed the daemon will communicate the state back to the product.
The future below summarizes this processing:
Figure 18. Batch Daemon Processing
Using Timed Batch

Note: This feature only applies to Oracle Utilities Application Framework V4.2.x and above only.
Note: This feature only applies to selected product supplied processes only.
One of the features of the Oracle Utilities Application Framework is the ability to create timed batch
processes. Typically, most batch processes are executed as a single execution on a regular time period
such as once a day, once an hour etc. In some implementation scenarios, it is required to run a batch
process continuously (such as a daemon) to process data as it is found. The Oracle Utilities Application
Framework introduced a feature to allow implementations to create processes that are run continuously.
The figure below illustrates the difference in the processing styles:
Figure 19. Concept of Timed Processes
The concept is as follows:
• The batch program must be designed to run continuously. Existing processes in the product cannot
be converted from non-timed to timed just using configuration. The Oracle Utilities SDK contains
information about writing continuous batch programs.
• An instance of the timed batch program runs for a timer interval and then completes on next commit
after the interval is reached. After completion a new instance is automatically started. This simulates
a continuous execution whilst minimizing performance impact on the overall system.
• The batch control for timed processes must be configured with additional information including:
– Timer Interval. The duration each instance of the batch process will execute.
– Timer Active. This controls whether the process is executing or not. The process will only execute
when the timer active is set to true/Yes.
– UserId/Batch Language. Userid used for authorization and language for batch messages
– Email Address. Optional, email address used for monitoring for error executions.
• The process must be started manually initially to start the process executing.
• To stop a timed process, set the Timer Active to false.
Level 2 Caching in Batch
As with the rest of the architecture for Oracle Utilities Application Framework based products, a level 2
cache is created in the cluster, within each theadpool instance, to cache commonly used configuration
data for the processes in that threadpool. The Oracle Utilities Application Framework will manage the
population of this cache automatically. Some processes that operate on this configuration data requires
that this cache be disabled to update the information in that cache correctly. This technique is only
applicable to specific processes used to manage configuration migration and security. For these
processes it is recommended to create a special threadpool with L2 Caching turned off. To set up a
threadpool with caching disabled the following process should be used:
Use the bedit.sh -l l2cache command which will create a new template for use in the settings.
Set the following settings (settings not mentioned should remain as defaulted):
Level 2 Cache Settings
SETTING RECOMMENDED SETTING
daemon false
l2 OFF
• Create a threadpool named appropriately, for example L2OFF, with a minimum number of threads to
process the utilities. Remove all other pool settings. Save the settings.
• When needed start the threadpool using the threadpoolworker.sh -l l2cache command.
• Ensure the processes have the above threadpool as the recommended one to execute in.
Level Of Service
Note: This feature is only available in Oracle Utilities Application Framework V4.2.0.2.0 and above.
One of the newer features of Batch processing is the ability to configure a level of service check on the
batch control to check the latest execution of the process against some criteria to ascertain whether it
meets service expectations. This facility is designed to provide basic service level feedback.
By default, the facility is disabled with the message Disabled - Level of Service reporting is not enabled
for this batch process displayed on the Batch Control screen. This indicates that the level of service is
not configured for this batch.
To use this facility the following needs process to be performed:
• An algorithm of type Batch Level of Service must be created using the Oracle Utilities SDK or using
ConfigTools using Service Scripts. This algorithm must be defined as an algorithm of this type and
contain the logic to check the last execution against a target (the logic is up to your business criteria).
The following algorithm types are supplied that can be used as a basis for algorithms.
Supplied Algorithm Types
ALGORITHM TYPE COMMENTS
F1-BAT-ERLOS Compare Count of Records in Error to a threshold
F1-BAT-LVSVC Evaluate Error Count and Time Since Completion - Typically used for Timed
processes
F1-BAT-RTLOS Compare Total Batch Run Time to a threshold
F1-BAT-TPLOS Compare Throughput to a threshold
• Create an algorithm of the type above (or one created earlier) with the targets. For example:
Figure 20. Example Algorithm entry
• On the Algorithms section for individual Batch Control configure the new algorithm with the appropriate
service levels on the algorithm definition.
Whenever the batch control is displayed the level of service will be assessed accordingly.
For example:
Figure 21. Example algorithm on batch control
Using Queries to Monitor Batch
By default, all the monitoring information is available from the Batch Run Tree or via realtime using the
JMX interface (directly or via Application Management Pack for Oracle Utilities). Whilst this information
is available via the online, it can also be available via an appropriate query. The query below will
reconcile all the executions of the product in one query. This query is a sample only:
select t1.BCD BATCH,t1.BNR,t1.ID SCHID,SUBSTR(t1.TIME,6,14)

STARTTIME,T1.BATCH_THREAD_NBR,
DECODE(t2.ID,null,'Running',SUBSTR(t2.TIME,6,14)) ENDTIME,
DECODE(T3.THREAD_STATUS,10,'Pending',20,'In
Progress',30,'Error',40,'Completed',50,'Ready','??') STATUS,
t1.BATCH_BUS_DT,
T1.BATCH_RERUN_NBR,
DECODE(SIGN(t2.TOTAL - t1.TOTAL),-1,(t2.TOTAL - t1.TOTAL0),(t2.TOTAL -

t1.TOTAL)) TIMESEC, t1.REC_PROC_CNT, t1.REC_ERR_CNT
from
(select b.batch_cd BCD,b.BATCH_NBR BNR,b.SCHEDULER_ID

ID,b.BATCH_THREAD_NBR,b.BATCH_RERUN_NBR,
l.MESSAGE_PARM time,a.BATCH_BUS_DT,b.REC_PROC_CNT,b.REC_ERR_CNT,
SUBSTR(l.MESSAGE_PARM,9,2)*3600*24 +
SUBSTR(l.MESSAGE_PARM,12,2)*3600 +
SUBSTR(l.MESSAGE_PARM,15,2)*60 + SUBSTR(l.MESSAGE_PARM,18,2) total,
SUBSTR(l.MESSAGE_PARM,15,2)*60 + SUBSTR(l.MESSAGE_PARM,18,2) total0,
l.MESSAGE_SEQ SEQ
from CI_BATCH_RUN a,
CI_BATCH_INST b,
CI_MSG_LOGPARM l
where b.SCHEDULER_ID=l.SCHEDULER_ID
and a.BATCH_CD=b.BATCH_CD
and a.BATCH_NBR=b.BATCH_NBR
and a.BATCH_RERUN_NBR=b.BATCH_RERUN_NBR
and l.MESSAGE_SEQ=(select min(x.MESSAGE_SEQ)
from CI_MSG_LOGPARM X
where X.scheduler_id=l.scheduler_id)) T1,
(select b.batch_cd BCD,b.BATCH_NBR BNR,b.SCHEDULER_ID

ID,b.BATCH_THREAD_NBR,b.BATCH_RERUN_NBR,
l.MESSAGE_PARM time,a.BATCH_BUS_DT,b.REC_PROC_CNT,b.REC_ERR_CNT,
SUBSTR(l.MESSAGE_PARM,9,2)*3600*24 +
SUBSTR(l.MESSAGE_PARM,15,2)*60 + SUBSTR(l.MESSAGE_PARM,18,2) total,
l.MESSAGE_SEQ SEQ
from CI_BATCH_RUN a,
CI_BATCH_INST b,
CI_MSG_LOGPARM l
where b.SCHEDULER_ID=l.SCHEDULER_ID
and a.BATCH_CD=b.BATCH_CD
and a.BATCH_NBR=b.BATCH_NBR
and a.BATCH_RERUN_NBR=b.BATCH_RERUN_NBR
and l.MESSAGE_SEQ=(select max(x.MESSAGE_SEQ)
from CI_MSG_LOGPARM X
where X.scheduler_id=l.scheduler_id)) T2,
CI_BATCH_THD T3
where T1.ID=T2.ID(+)
and T1.BCD=T3.BATCH_CD
and T1.BNR=T3.BATCH_NBR
and T1.BATCH_THREAD_NBR=T3.BATCH_THREAD_NBR
and T1.BATCH_RERUN_NBR=T3.BATCH_RERUN_NBR
and DECODE(t2.ID,null,'Running',SUBSTR(t2.TIME,6,14)) is not null
order by STARTTIME, T1.BATCH_THREAD_NBR
The following information is extracted:
Query Columns
COLUMN USAGE COMMENTS
BATCH Batch Control Identifier This is used to identify the process.
BNR Batch Run Number This is the system generated run number
SCHID Scheduler Identifier This is an internal generated number to identify

an individual execution of a process or restart
STARTTIME Start Date and Time This is the date and time of the start of the
processing in the format of the session
BATCH_THREAD_NBR Thread Number for This is the thread number. The BATCH, BNR,
execution SCHID and BATCH_THREAD_NBR are used as the
key for the query.
ENDTIME End Date and Time This is the date and time of the end of the
processing in the format of the session
STATUS Status of process Status of the process. Either Completed

(successful) or Error (unsuccessful)
BATCH_BUS_DT Business Date The Business Date used to process these

records. This can be used to group executions
across processes if necessary
BATCH_RERUN_NBR Batch Rerun Number If the process was a restart of an extract, then
this will be populated with the rerun number. A
value of zero (0) is used to denote processes that
do not use this capability, or this is not a rerun.
TIMESEC Seconds difference This is the difference between STARTTIME and

between start and end ENDTIME in seconds. Useful for calculations.
date times
REC_PROC_CNT Record Count The number of records processed in the thread.
REC_ERR_CNT Error Record Count The number of records that errored in the thread.
Parameter Overrides
The various submission methods allow for parameters for the processes to be set at various levels and
overridden at lower levels in the submission method. This allows implementations to be flexible in how
they are defined and how they are used in the execution of processes. The figure below illustrates the
order of precedence for parameters by submission method:
Figure 22. Parameter Override Levels
Parameter Override Levels
COMMAND LINE SCHEDULER INTERFACE ONLINE SUBMISSION
Batch Interface defaults in

OUAF_BATCH interface
GLOBAL scoped defaults in

Parameters On Batch Control Parameters On Batch Control
Batch Process specific

scoped defaults in
Parameters are expressed in

submitter properties files
Submission Record
Command Line Overrides Command Line Overrides
The lower levels can override the higher levels when configured to do or at the appropriate time based
upon submission method.
Parameter Guidelines
When configuring and using parameters the following best practices apply to reduce maintenance costs:
• Set Parameters at higher levels. Setting your parameters at higher levels reduces maintenance
costs and simplifies submission.
• Only Override a parameter when necessary. Only override the parameters at lower levels if it is
necessary. This reduces maintenance costs.
• Internal defaults should not be relied upon for non-development use. In some submission
methods internal defaults are used as root level parameters. They are provided for developers to unit
test their code for various testing techniques.
• The command line options should only be used for reruns or off schedule (a.k.a. special runs).
This avoids updating the configuration files for one-off or special processing. The only exception to
this rule is that the Business Date parameter should be specified on the command line to ensure
consistency across processes.
• Batch Control is not used for Command Line Submission Method. Whilst it is possible to define
parameters on the Batch Control for use in some submission methods the command line submission
method does not use the Batch Control. The main reason for this is that the scheduler that executes
the process needs control and may be remote from the product.
• It is not recommended to set MAX-ERRORS at a global level. This should only be specified at an
individual thread of a background process level.
• Setup Security At The Highest Level. Avoid security issues and reduce maintenance costs by
settings global users as necessary.
• It is not recommended that the default SYSUSER be used as the userid specified in
background processes. SYSUSER is the initial default user for the Oracle Utilities Application
Framework and is only used to input additional user in the initial stages of configuration. Most
implementations create a dedicated user record to delineate background processes from online
processes.
Setting The Error Tolerance

By default, there are two circumstances where a background process will not complete successfully.
First of all, there is some technical issue with the environment or program and the other is if all records
processed fail some business rule. The latter condition may not be appropriate for your site. For
example, if all but one payment fails in the payment background processes then the process is still
considered complete.
To support a more realistic tolerance, it is possible to set a limit on the number of errors tolerated before
the process should be cancelled. At the thread level, the MAX-ERRORS parameter can be used to specify
a thread level error tolerance where the thread will be cancelled when the tolerance is reached or
exceeded.
The default value of MAX-ERRORS is 0 (zero) which turns off the facility. Any appropriate non-zero value
will then become the error tolerance limit for the thread.
Setting the appropriate value for your site will require business approval in line with your sites
organization business practices.
Note: The MAX-ERRORS parameter is applicable to business errors only. System errors (SEVERE
errors) will terminate the process immediately.
Altering Commit Interval and Timeout

Note: Timeout does not apply to Java based processes and is not used for any batch process in Oracle
Utilities Application Framework V4.3 and above.
There are two parameters that can be altered to control the amount of resources a background process
uses when it executes. While most implementations reuse the default values supplied with the product,
it is possible to alter the values to tune the performance of background processes and allow background
processes to be executed during peak application usage periods.
The Commit Interval parameter controls the Unit of work on the background process. It controls after
how many primary objects are processed before a commit point is taken, also known as commit
frequency. It controls the amount of work the database must do and when a checkpoint is taken for
restart purposes. At the commit point in a background process, all the outstanding work, since the last
commit, is reflected on the database and a checkpoint is written on the batch control record for the
process. You usually take the default for the process, but it can be adjusted according to the
circumstances.
The higher Commit Interval the value specified the less commit points are taken. Typically commit
points can be expensive transactions in a database so most implementations try and minimize them.
The lower value the more commit points. The latter is desirable when you are running background during
online hours as it reduces the resource hit the background process has on online processes.
Specifying a large value for Commit Interval can cause larger than normal rollbacks to be performed
by the database. This can cause a strain on the database and hardware. The longer the unit of work the
more work the database must do to roll it back in case of a failure.
The Commit Interval can have advantages and disadvantages depending on the situation and the
value:
Comparison of Approaches
HIGH VALUE FOR COMMIT INTERVAL LOW VALUE FOR COMMIT INTERVAL
Larger Unit of Work Smaller Unit of Work
Longer rollback in case of failure Shorter rollbacks in case of failure
Can increase throughput on lightly loaded system Can allow background to work harmoniously with
online
Less Commits in process (Less checkpoints) More Commits in process (More frequent
checkpoints)
Lower Concurrency (higher impact on other users) Higher Concurrency (lower impact on other users)
The second parameter Timeout (in minutes) controls how long a solution set is held by the process.
When Oracle database processes a set of records it typically holds a snap shot of these records to save
processing time. If the set is held too long, the records may not reflect the state of the database, so it is
a good idea for the Oracle database to maintain the currency of this data regularly. Within the
background process this is controlled by setting this value to prevent the snapshot being discarded by
Oracle database and causing an abort. If the records are held too long an ORA-1555 Snaphot too old
error is generated and the process aborts.
The Timeout and Commit Interval parameters are tunable parameters to affect the impact of the
background processes on the other processes running and prevent internal database errors. It is also
important to understand their impact to ascertain whether any change is required. The following rules of
thumb apply to setting the values:
• It is recommended that the Commit Interval should not be set to one (1), unless otherwise instructed,
as this value may causes excessive database I/O and therefore performance degradation.
• For light jobs (short duration, single threaded, small numbers of records etc), the default value for
Commit Interval may satisfy your site performance requirements.
• For heavy jobs (long duration, multi-threaded, large number of records etc), then a value for Commit
Interval of between 5 (five) to 200 (two hundred) is recommended.
• The value of the Commit Interval directly affects the size of the redo logs allocated to the database.
The higher the commit interval the larger the redo logs need to be to hold the in-process objects. Work
with your sites DBA groups to come up with a compromise between redo logs and Commit Interval.
During processing of any background process, a main object is used to drive the process. For example,
in BILLING the main object is Account. The BILLING process loops through the accounts objects as it
processes. For other processes it is other objects that are considered the main object. This main object
type is used to determine when a transaction is complete.
For both Timeout and Commit Interval this is important as:
• At any time in a process a commit for objects processed may be caused by the reaching the Commit
Interval or the time limit set on Timeout, whichever comes first.
• The setting of Commit Interval and Timeout has impact on the amount of memory the JVM memory
space allocated to the individual threads. Higher values of both require more memory to hold the data.
PLUG IN BATCH
Note: This capability is available for Oracle Utilities Application Framework V4.3.0.4.0 and above only.
One of the new features of the Oracle Utilities Application Framework is the ability to define the
processing necessary for a batch process without the need for creating a java-based extension in the
Oracle Utilities SDK. This is known as Plug In Batch and is designed to allow implementations to quickly
build batch processes without the need for complex coding.
The idea behind Plug In Batch is that you can develop in a series of algorithms in Java, Scripting or
Groovy (the latter two are supported for Cloud implementations) to break a batch process into its
constituent parts for processing. The Oracle Utilities Application Framework will take care of any data
access, restarting, checkpointing, multi-threading etc.
The following algorithms are available:
Plug In Batch Algorithms
ALGORITHM TYPE COMMENTS
Select Records This algorithm typically contains an SQL statement to filter the records to
process including threading
File Upload This algorithm is used for processing XML, Fixed or CSV formatted files
Process Record This algorithm takes the information from either Select Records or File Upload
algorithm to process the records appropriately. For file extracts, this algorithm
contains the logic to format the output
Post Processing This algorithm provides the ability to provide extra logic if the Process Record
processing is successful for the record set.
Error Post Processing This algorithm provides the ability to provide extra logic if the Process Record
processing is not successful for the record set.
The first algorithms (Select Records and File Upload) determine the set of records to process for the
batch process. Each record is passed to a Process Record algorithm to process the object (for file
extracts that means formatting and writing records). Optionally, if required, if the process is successful
then extra logic can be executed in the Post Processing algorithm. Conversely, if required, if the process
is not successful then extra logic can be executed in the Error Post Processing algorithm. The figure
below illustrates this processing:
Figure 23. Plug In Batch Algorithms
Note: Refer to the ConfigTools Best Practices for more advice on building Plug In Batch.
When building an algorithm for Plug In Batch consider the following:
• SQL Statement in Select Records should consider Threading. In the SQL statement, consider
added support for f1.lowId and f1.highId in your SQL for automatic thread handling. There are
numerous examples shipped with the product to illustrate this.
• Consider using Bind Variables in your SQL. Several internal bind variables are available to use for
your SQL statement if necessary to determine the subset of records to process.
• Use F1-GENPROCEX as an example for extracts. A sample Process Record script is provided as an
example of file extract algorithms including formatting.
• Use Samples for File Import. Several samples are available as Plug-In Scripts of Algorithm Entity
Batch Control - File Upload. Use these samples as an indication of what is possible. For example:
Figure 24. Sample Plug In Scripts for File Processing
• Post Processing and Error Post Processing for Process Level Control. These algorithms are
typically used to link processes in the Oracle Scheduler, process chaining, file footer processing or
process cleanup activities after the last thread of the process has completed.
ORACLE CORPORATION
Worldwide Headquarters
500 Oracle Parkway, Redwood Shores, CA 94065 USA
Worldwide Inquiries
TELE + 1.650.506.7000 + 1.800.ORACLE1
FAX + 1.650.506.7200
oracle.com
CONNECT W ITH US
Call +1.800.ORACLE1 or visit oracle.com. Outside North America, find your local office at oracle.com/contact.
blogs.oracle.com/theshortenspot linkedin.com/in/theshortenspot twitter.com/theshortenspot
Copyright © 2007 - 2019, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof
are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed
orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be
reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or
registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of
Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0219
Batch Best Practices - Oracle Utilities Application Framework
February 2019

Batch Best Practices PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Batch Best Practices PDF

Uploaded by

Copyright:

Available Formats

Batch Best

WHITE PAPER / FEBRUARY 2019

Batch Concepts ........................................................................................... 6

Batch Processing At A Glance..................................................................................................... 6

Batch Controls ............................................................................................................................. 8

Batch Parameters .......................................................................................................................11

Multi-Threaded Processes ..........................................................................................................14

Extract Process ..........................................................................................................................16

Batch Architecture ..................................................................................... 16

Batch Technology .......................................................................................................................17

Batch Initiation ............................................................................................................................18

Batch Interface ...........................................................................................................................18

Batch Objects .............................................................................................................................20

Configuring Batch Architecture .................................................................. 22

Determining Cluster Configuration..............................................................................................23

Setting Submitter Architecture (optional) ....................................................................................29

Designing Your Threadpool Architecture ....................................................................................31

Implementing Cache Threadpools ..............................................................................................34

Implementing Administration Threadpools .................................................................................36

Administrating Threadpools ........................................................................................................37

Advanced Threadpools using Templates ...................................................................................37

Determining Threads ..................................................................................................................38

Batch Best Practices.................................................................................. 41

Use of Oracle Coherence ...........................................................................................................41

Using the Batch Daemon ............................................................................................................41

Using Timed Batch .....................................................................................................................42

Level 2 Caching in Batch ............................................................................................................44

Level Of Service .........................................................................................................................44

Using Queries to Monitor Batch ..................................................................................................46

Parameter Overrides ..................................................................................................................48

Parameter Guidelines .................................................................................................................50

Setting The Error Tolerance .......................................................................................................50

Altering Commit Interval and Timeout ........................................................................................51

Plug In Batch ............................................................................................. 52

One of the major channels of the Oracle Utilities Application Framework is

Batch Processing At A Glance

The processing is summarized below:

Figure 1. Summary of Batch Processing

An example of a Batch Control is shown below:

Batch Run Tree

An example of a Batch Run Tree is below:

Figure 4. Sample Restart Override

PARAMETER TYPE SCOPE COMMENTS

Batch Category Explicit Business This is used for reporting purposes on

Thread Number Explicit Technical This is the individual thread number to

Override Number of Explicit Technical The number of objects to process before a

Trace SQL Explicit Technical This setting enables or disables debug

Trace Output Explicit Technical This setting enables or disables debug

Batch Business Date Explicit Technical/Business This is an important submission parameter

Batch User Explicit Technical/Business This parameter is required at submission

Email Address Explicit Technical This is an optional parameter used by some

DIST-THD-POOL Implied Technical This is a hidden parameter in the collection

MAX-ERRORS Implied Business This is a hidden parameter which when

The capability can be described as follows:

Figure 5. Sample Threading

The concept of threading has advantages and disadvantages:

Command Line Utilities

OBJECT PRIME TABLE USAGE

Batch Job CI_BATCH_JOB Submission initiation object used by Online

The batch architecture is based upon the following concepts:

These execution concepts are shown below:

CONFIGURING BATCH ARCHITECTURE

50. Advanced Environment Miscellaneous Configuration