Generators

Generators are classes that produce other classes for execution. XML rules are configurable with expressions and conditions, and generators are used to execute these rules. Generators are responsible for loading the rules, performing error checking, translating the rules and creating java source code at run time for the rules then compiling them into classes. They also create an instance of the run time generated class and return them to the caller for execution.

Generators have the following functions:

  • Load rules.
  • Parse rules and check for errors. Report Errors if needed.
  • Translate rules to java code and compile the class.
  • Cache the translation for next time lookup.

Generators run in the modes described below. The mode can be set in the application property file, such as PAS.properties. Information regarding the PAS.properties file can be located on Oracle's Technology Network in the OIPA 11.0.0.0 Documentation Library E78460_01.

The PAS.properties file section where you set the application mode:

# application mode ( DEVELOPMENT or PRODUCTION )

# Development mode is where configuration changes are allowed.

# Production mode is where configuration change is a new release and JVM is restarted when they are changed.

application.mode= DEVELOPMENT

In DEVELOPMENT mode the system allows rules to be changed in the database during application runtime. This mode should only be used during active development. Generators load the rules every time, generate a hash key and cache the generated classes associated with the hash key. If the rules are changed using Oracle Insurance Rules Palette, then the hash key generated will be different, which will force the generator to translate and compile again. If the rules are not changed then it reaches out to its cache and returns the cached instance.

application.mode= PRODUCTION

In PRODUCTION mode the system does not allow the changing of rules. If rules are modified, it requires that all JVMs be stopped and restarted so that caches are cleared. In production mode, rules are cached as well as the translated classes. Hence no check is made to ensure changes.

Generators support debugging mode and non-debugging mode. The Rules Palette can debug into transactions and do a line by line execution of the math section using a web service. In order to debug via the Rules Palette, the application should be started in debugging mode.

Debugging mode adds a lot of extra information to enable remote debugging, and therefore, generators create extra lines of code.

The PAS.properties file section for settings debugging:

# This property allows remote level debugging or not. Yes or No.

debug.remoteDebugging=No

If set to No, then the application will not support remote debugging at runtime. If set to Yes, then remote debugging is supported. It should NEVER be set to Yes in a Production environment.

To support developer debugging of activity processing, Generators can save the generated classes to a local file system if configured in the property file. If debug.IdentiyTranslator is set to Yes, then in the java files generated, at the end of each file, it will add a comment identifying the translator class and the line number that generated that line of code. This is extremely useful in debugging the generated source code and changing it for future needs.

The PAS.properties file section of settings for debugging properties:

# Directory to save generated source code.

# This property will be used to debug issues with sre processing.

# Generated source code while processing will be saved in the

# directory specified. Only to be used in Non Production environment.

# debug.identifyTranslator will write comments for every line identifying

# the translator(line number) that generated that part of code.

 

debug.SaveGeneratedClass=Yes

debug.identifyTranslator=Yes

debug.SaveGeneratedClassDirectory=c:

temp

 

There are different types of generators for different purposes. A few are described in the next section of this document.

PasTransactionGenerator

PasTransactionGenerator is a Generator specific to OIPA transactions. It understands the rules of the OIPA transaction and generates the classes suited to its processing needs. All generated classes by this Generator extend from PasTransactionBll, which implements the basics of OIPA activity processing. Logic Flow of the Transaction Generator

  1. Start – Shared rules engine calls the static method in the Generator for activity processing. PasTransactionGenerator. getTransactionBllForProcessing
  2. Get Generator Instance - Creates an instance of a generator class per transactionGUID. There is only one instance of the Generator per transaction, but many instances of the Generator for different transactions. This prevents multiple threads calling to process activities of the same transaction type and simultaneously translating the same rules. Only one thread translates the rules for a transaction and other threads, it there are any, wait for the first thread to complete. It then uses the class for processing.
  3. Production Cache – The Generator then looks at the cache to see if a class exists for this transactionGUID. In Development mode, the cache will not contain the key. In Production mode, if the transaction is already translated, it will pick it up and return.
  4. Load Rules, Compute HashKey – If false in the above decision, the Generator loads the rules from the database. It computes the unique hash key for the rules XML.
  5. Check Cache – It then checks in the cache to see if it has a class file for the hash key generated. In Development mode, if the transaction is updated then the hash key will be different and it will force the Generator to translate again.
  6. Generate – It will parse the rules, translate the rules using translators and then compile the generated java classes. It also saves to the file system if specified in the property file.
  7. Update Cache – It updates the cache depending on development or production mode for future use. Future calls with the same transaction GUID and same hash key are not translated.
  8. Return Class – Returns the instance of the generated class to the caller.

SegmentCalculatorGenerator

SegmentCalculatorGenerator is used to create classes at runtime for segment calculation based on the rules. This creates classes specific to the OIPA system. SegmentCalculator follows the same algorithm as the PasTransactionGenerator except that it has only one instance of the generator class for all segment rules where PasTransactionGenerator has one instance per transaction GUID. At any given point of time in a JVM, only one segment calculation can be translated.

Note: If there are multiple requests to retrieve a segment calculator class, one gets through and others are blocked until the class is returned from the cache or translated and compiled.

MathEngineFactory

This is the stand alone math Generator. This class is not named like other classes, which end in the word Generator. It is good to note this, to avoid confusion regarding it being a Generator. The MathEngineFactory loads the rules with only math sections and creates a class that executes the math rules and returns the results. This is an independent math generator that is used by valuation, exposed computation and any module that has math sections that need to execute.

FunctionCallGenerator

FunctionCallGenerator is used to create function code. The generated function rule classes are embedded within the transaction, segment or math classes. These Generators are not thread synchronized because currently they are called from one of the above generators and they are throttled above.

ScreenEventGenerator

There are four types of ScreenEventGenerators: OnLoadGenerator, OnSubmitGenerator, OnClickGenerator and OnChangeGenerators. These are used to process the rules at three different events of the application. They are not related to activity processing but part of the shared rules engine as they involve processing math calculation.

RequirementProcessorGenerator

The RequirementProcessorGenerator generates Java code for requirement processing based on the configuration provided in the Requirement Definition XML. The generator is a part of the shared rules engine but is not actually related to activity processing.

Math

The Math module is a sub-component of the shared rules engine, which is responsible for executing any math sections in the rules. In a rule, all tags between the <MathVariables> element are handled by this sub-component.

Conceptual Math Functionality

  1. The Generator that generates java source for the <MathVariables> section calls the MathDal with the location to the MathVariables element in the rules XML file.
  2. The MathDal classes parse the element and its sub-elements and create a list <MathStatementDcl> and returns it as an output. MathStatementDcl represents the entire tree hierarchy of the math section with loops and MathIF's.
  3. The above List <MathStatementDcl> is sent to JavaMathTranslatorBll for translation. Each math statement Dcl is translated and the corresponding java code for that statement is set in the MathStatementDcl itself.
  4. JavaMathTranslatorBll returns an instance of ProcessContext that contain lots of information. It contains:
    • List of MathVariables declared
    • List of functions called
    • Other structures for dependency and debugging purposes
  5. Generators get the ProcessContext and generate the final class with variable declaration, statements and function calls for compilation and execution.