OUAF: Plug-in Driven Batch Programs (Part…1)
Usually, OUAF batch programs are written in Java. Lately Oracle
has introduced a feature to build batch programs using plugins that are written
either in scripting or groovy.
With Plug-in driven batch program feature, the implementer shall
create custom batch programs in Oracle utilities SaaS products such as CCS
(Customer Cloud Service), MSCS (Meter Solution Cloud Service) and WACS (Work
and Asset Cloud Service). This feature is available for on-premises OUAF (C2M,
MDM, WAM, MWM) products as well.
OUAF framework provides base background processes
that can call series of algorithms to carry out specific business logic that needs
to be performed. These are called plug-in driven background processes.
(1) Processing
System Records: Acts on OUAF entity records
that are stored in the database tables. These types of processes require SQL to
select the records along with the logic to process the records.
(2) Uploading
Records - Imports data from a file and adds new entity records in the database.
These types of processes require an algorithm to map the data from the file to
appropriate new OUAF entity records to be created in system
(a) Ad-hoc
Process: Implementer can create specific custom business logic that needs
to be performed on a group of records. This
type of custom batch program shall be created by duplicating base batch control
Plug-in Driven Generic Template (F1-PDBG).
(b) Extract Process: Implementer shall use this to produce file extracts that needs to be integrated with external systems. This type of custom batch program shall be created by duplicating base batch control Plug-in Driven Extract Template (F1-PDBEX).
Ad-hoc Process: Base batch control Plug-in Driven Generic Template (F1-PDBG). User can duplicate this to create custom batch program.
Plug-in Driven Batch process supports the following systems events. Implementer shall create custom algorithms and plug into the appropriate system event spots to meet business requirements.
|
System
Event |
Algorithm
usage |
|
Select Records |
Record set
selection. Used to define the SQL to use to select the records to process |
|
Process
Record |
Process
specific record in record set |
|
Post Processing |
What additional
processing is needed for successful jobs. This is called after all threads
are completed |
|
Error
Post-Processing |
What
additional processing is needed for jobs in error. This is called if the
batch process fails to complete due to an error. |
|
File Upload |
File Input
Processing (Replaces Select Records). This is used to upload records from a file |
|
Level
of Service |
Determine
the Level of Service provided by a batch control. |
(i) Select Records System Event: This algorithm will
define the SQL as parameter. The batch job will directly access the SQL
parameter value in the metadata. This algorithm contains 3 parameters:
- SQL Statement - SQL statement with record selection criteria (supported with pre-defined bind parameters). Note that implementer is responsible for performance of the SQL statement
- Strategy - how the records will be processed (Job-Level SQL Select or Thread-Level SQL Select)
- Key field - used to denote records to process (usually, the primary Key of the MO or Table)
(ii)
Process Record – System Event: This algorithm process
records passed from ‘Select Records’ Plug-in. The algorithm plugged into this
spot is responsible for doing the work for each record based on the desired
logic. This is implemented as a ‘Service Script’ and may contain logic to
process database transactions and optionally output records to a file. This
plug-in spot has the following hard parameters:
|
Hard
Parameter |
Parameter
Usage |
|
parm/hard/* |
Hard parameters
(including ids) |
|
parm/hard/isFirst |
Used
for header processing (Set to false for non-extract programs) |
|
parm/hard/isLast: |
Used
for footer processing (Set to false for non-extract programs) |
|
parm/hard/selectedFields/* |
Fields
passed from SQL |
(iii) Post Processing – System Event: This algorithm executes after all the threads of a given batch job have completed. This allows for some special processing to occur at the end of a batch job that is completed successfully. Example could be another dependent batch job can be kicked off after successful end of batch job.
(iv) Error
Post-Processing - System Event: This algorithm executes when a batch process
encounters an error that causes execution to stop. This allows for some special
processing to occur to handle the failure of the batch job. Example could
be an outbound message service may be invoked to perform a task related to the
failure.
(v) File Upload - System Event: This algorithm is used if implementer needs to build an import process from a file to the product objects/MO. This algorithm associated with the batch control is responsible for using provided APIs to read the content of the file and store the data in appropriate table (eg: staging table).
(vi) Level of Service – System Event: This
algorithm is used to check the performance of the batch process whether is
running as expected or it could analyze the data processed by the background
process to assess quality of the data. This algorithm will return following
value to indicate the 'level of service'.
- Normal - the algorithm did not detect any issues
- Warning - the algorithm found some issues that may or may not indicate a problem
- Error - the algorithm found some issues that should be investigated
- Disabled - the algorithm could not properly execute the level of service logic
