OUAF: Plug-in Driven Batch Programs (Part…1)

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.

 There are two types of plug-in driven batch processes supported by OUAF:

 

(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

 

 Processing System Records

OUAF provides the two different batch process templates to support plug-ins for selecting and processing the records:
 

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

           Example:

(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