Understanding Activities
Activity processing is controlled by various attributes associated with the activity. Activities are instances of XML transaction rules being applied on data at a specific level in the application. The AsActivity table stores records for activity processing that house applicable business event data. The AsTransaction table stores the XML transaction logic that processes activity data. There are three important areas to focus on when discussing activities: transaction type, activity type and activity status. Each of these areas is tracked using code values. These codes may be found in the AsCodes table or from Admin Explorer | Codes in the Rules Palette. The code values used in activity processing are used by the system and should not be changed.
Transaction Types
The transaction type code, which is stored in AsTransaction in the XML transaction rule associated with the activity, plays an important role in activity processing. The transaction type code specifies the type of data or the level where the activity will process. This then drives the type of processing, such as math or valuation, that should be executed by the system. The type code definition can be located in the AsCode table under AsCodeTransactionType.
| Transaction Type | Description |
| Policy Financial | This transaction executes at the policy level and may or may not have financial impact. It participates in undo/redo and can be recycled from the user interface. |
| Policy Financial Non Reversible Non Reversing | This transaction executes at the policy level and may or may not have financial impact. It does not participate in undo/redo and cannot be recycled via the user interface. |
| Policy Document | This transaction executes at the policy level and generates documents or reports. It participates in undo/redo and can be recycled from the user interface. |
| Policy Document Non Reversible, Non Reversing | This transaction executes at the policy level and generates documents or reports. It does not participate in undo/redo and cannot be recycled from the user interface. |
| Policy Financial Reversible Non Reversing | This transaction executes at the policy level and may or may not have financial impact. It participates partially* in undo/redo and can be recycled from the user interface. |
| Policy Document Reversible Non Reversing | This transaction executes at the policy level and generates documents or reports. It participates partially* in undo/redo and can be recycled from the user interface. |
| Plan Financial | This transaction executes at the plan level and may or may not have financial impact. It does not participate in undo/redo and can be recycled via the user interface. |
| Plan Financial Non Reversible Non Reversing | This transaction executes at the plan level and may or may not have financial impact. It does not participate in undo/redo and cannot be recycled via the user interface.. |
| Plan Document | This transaction executes at the plan level and generates documents or reports. It does not participate in undo/redo and can be recycled via the user interface. |
| Plan Document Non Reversible Non Reversing | This transaction executes at the plan level and generates documents or reports. It does not participate in undo/redo and cannot be recycled via the user interface. |
| Client Financial | This transaction executes at the client level and may or may not have financial impact. It participates in undo/redo and can be recycled from the user interface. |
| Client Financial Non Reversible Non Reversing | This transaction executes at the client level and may or may not have financial impact. It does not participate in undo/redo and cannot be recycled via the user interface. |
| Client Document | This transaction executes at the client level and generates documents or reports. It does not participate in undo/redo and can be recycled via the user interface. |
| Client Document Non Reversible Non Reversing | This transaction executes at the client level and generates documents or reports. It does not participate in undo/redo and cannot be recycled via the user interface. |
| Client Financial Reversible Non Reversing | This transaction executes at the client level and may or may not have financial impact. It does not participate in undo/redo and can be recycled via the user interface. |
| Client-GCQuote | This transaction executes at the Client level and may or may not have financial impact. This does not participate in undo/redo. |
*Partially: May be inserted between existing active activities without invoking undo-redo on any of the processed activities after it. Once processed, will be recycled / reprocessed due to the reprocessing of any "Policy Financial" or "Policy Document" activities prior to it.
Activity Types
Each activity record has an activity type code that is stored in the AsActivity table. The type code definition can be found in the AsCode table under AsCodeActivityType. These types should not be confused with the transaction type code or the status of an activity, but instead, used in conjunction with them to understand how an activity was generated and what status the activity is currently in. Activities can be generated by an end user or the system may automatically generate activities because a dependent activity's data was changed.
OIPA Activity Types
| Code Name | Code Value | Description |
| Natural | 01 | Activity entered manually by a user. Activity that was spawned for the first time from a natural activity. A spawned activity even though system generated can be considered a natural activity because the user manually processed the activity that spawned it. Activity created by a web service. |
| Reversal | 02 | Reversal activity that was created by an end user when either manually deleting or recycling an activity. Spawned activity that was reversed because the originating activity was manually reversed. |
| Undo | 03 | Activity that is created to reverse an active activity that is created by the system as part of running another reversal or as part of processing a pre-dated activity. This behaves exactly as the Reversal but just differentiates itself as system generated. |
| Redo | 04 | System generated activity that was automatically created due to the generation of an Undo activity. |
| ActivitySequenceReversal | 05 |
Reversal activity sequence that was created by an end user when either manually deleting or recycling an activity sequence. |
Activity Status
The activity statuses are fundamental for activity processing and historical recording. They indicate at the activity level the status of that activity record. In comparison, the activity types section records the type of activity that was processed. The activity status, with the date stamp in current and history records, identifies the significant point of process and provides internal control for activities.
Note: Please refer palette config guide to get the details of all the statuses. Few of them are mentioned below.
Status Codes
| Code Name | Code Value | Description |
| Active | 01 | Indicates the activity is active. Refers to current data that has completed activity processing and math calculation. This includes processing, any changes to table and inserting XML to write to the table. No more processing can be done on this activity. |
| Pending | 02 | The activity is not yet processed. Pending data requires action before applying to current processing and math calculation. All required data must be entered and the activity processed to change the status from pending to active. |
| Pending Ready | 09 | An attempt was made to run the activity but was unsuccessful. |
| Shadow | 12 | This activity is effectively deleted from the system from an end user perspective as it is a result of an activity being reversed. It is available in the database and system for auditing purposes. |
| NUV Pending | 13 | The activity is active but it does not have NUVs for some or all of the funds associated with activity processing. This will process later when NUVs become available. This status does not invoke undo/ redo processing for future active activities. |
| Gain Loss Pending | 14 | This activity is active but gain loss calculation is pending and is not complete. This will be processed later when NUVs are available. This status does not invoke undo/ redo processing for future active activities. |
| Pending Shadow | 34 | An activity whose data was entered, but never processed and then deleted. |
| Client-GCQuote | 41 | An activity to indicate it belongs to group customer quote transaction type. |
| History | 52 | This is associated with Inactive Activity History. |
| Requirement Pending | 57 | An activity that has pending activity level requirements has this status. |
| Enrollment Pending | 59 | An Enrollment activity that is pending. |
| Queued | 58 | If the Transitions/Queue configuration is present and there are prior activities in NUV Pending status that share allocation funds with the current activity, the activity will go into Queued status when either a user or nightly cycle attempts to process the activity. It will remain in this status until there are no prior activities in NUV Pending status that share common funds in the activity allocations. |
| Activity Sequence Pending | 70 | A sequence activity that is pending. |
| Queued Activity Sequence | 71 | A sequence activity that has been queued. |
| Activity Sequence Error | 72 | A sequence activity that encountered an error during processing. |
| Processing Wait | 97 | This status implies that the activity is executing a long running task and is waiting for that task to complete. |
| Processing Stopped | 98 | This status implies that the activity has stopped processing a long running task and has ended in an error. |
Sub Status Codes
| Code Name | Code Value | Description |
| Canceled | 01 | Only applies to policy financial activities in Status Code 12 and 34. Activities in this sub status code are visible by default on the policy activity screen activity grid and are displayed as Canceled. Regular activities in Status Code 12 and 34 without a sub status code are not displayed by default on the policy activity screen activity grid. |
Error Status Codes
| Code Name | Code Value | Description |
| No Errors | 01 | Activity did not generate any business errors. |
| Business Error | 02 | Activity generated business errors. |
Activity Processing Flow
The activity processing flowchart reveals the system steps.
- Start – The shared rules engine receives a request from OIPA. The processing proceeds only if the activity is not active.
- If "Complete" – If standard activity processing should be invoked. Value of ActivityProcessType.
- It is sent by OIPA. It has three possible values: COMPLETE,SKIP_UNDOREDO_GENERATION or QUOTE. Strip down processing is done for options other than COMPLETE. QUOTE is for quoting an activity. SKIP_UNDOREDO_GENERATION for non-reversing activities, undo processing and for a specific instance during cycle processing after processing one activity in a policy. COMPLETE is the default option.
- Run Undos – This step looks for all pending undo activities that need to be run with an effective date after the current activity effective date and executes them. This logic calls back into OIPA and it calls the shared rules engine in recursion to execute the undo activity. If there are no activities in future relative to the current then this step is skipped.
- Generate Undo/Redo – This step looks for all activities that are active with an effective date after the current activity effective date. It creates an Undo/Redo for those activities.
- Move ready to pending – This looks for activities in Pending Ready (09) status on or before the current activity, and moves them to Pending (02) status.
- Run Undos – If in the previous steps there are any activities generated then this step runs the undos of the activities generated.
- Run related undo – This step checks if this activity is created by recycle and corresponding UNDO is still pending then execute here to make sure it is executed as the last before process Without Undo Redo Generation
- Load Processor – This loads the corresponding processor depending on the activity type code, activity status code and transaction type code.
- Process - Call the processor process method. This is explained in detail in the next section of this document.
- Business error on reversal – If an error occurs during activity reversal, the further processing stops and error is thrown.
Subcomponents of the Shared Rules Engine
Depending on the activity type that is sent for processing, an appropriate processor is initiated that handles the processing steps. The different processing types and diagram are as follows:
- Undo/Reversal Activity – Activity is already processed and it needs to be undone. Handled by UndoProcessorBll.java.
- Nuv Pending/Gain Loss Pending Activity – Activity is processed and is in active status, but some NUV's are missing or Gain Loss calculation is missing due to missing data. Handled by NuvPendingPolicyFinancialProcessorBll.java.
- Policy Level Activity – Activity at the policy holder that impacts the policy alone. Handled by PolicyFinancialProcessorBll.java.
- Client Level Activity – Activity at the client level that impacts client data and might impact all policies the client holds. Handled By ClientFinancialProcessorBll.java.
- Plan Level Activity – Activity at the plan level that aggregates all policies in the plan like reports or other changes to the plan. Handled by PlanFinancialProcessorBll.java.
- Document Generation – Activities that generate only reports are handled by DocumentProcessorBll classes. Separate classes exist for Policy Level Documents (PolicyDocumentProcessorBll ), Plan level documents (PlanDocumentProcessorBll ) and Client level Documents (ClientDocumentProcessorBll).
List of Processes as Part of Activity Processing
Depending on the processors, different sections of activity processing are executed. The processes are as follows:
- doPreliminaryForForward – Checks the transaction's eligibility for processing and loads NUVs for funds and prepares the activity for processing.
- doSuspense – Processes suspense for funds received.
- doValuation – Values the policy of all funds and calculates the cash value and other variables. This is called only when the transaction calls for the valuation in its rules. SRE calls the calling application to do the valuation using the interface. The calculated values are later used in other sections of activity processing.
- doMath – Calculates the math section of rules.
- doBusinessLogic – Runs the application process execution associated with the activity.
- doAssignment – Runs assignment processing.
- doTransition - Processes Transition element in Transaction Xml. If required, moves activity to Queued status and modifies its effective date.
- doPostAssignmentValidation - Processes the PostAssignmentValidateExpressions rule overridden at the Transaction level thus enabling validation and creation of business errors after Assignment processing.
- doDisbursement – Runs disbursement processing.
- doAccounting – Runs accounting for bookkeeping purposes.
- doSpawn – Runs spawn logic to spawn new activities based on the transaction's specific rules.
- doActivitySequence – Processed activities as per the sequence specified.
There are various sub processes that run during activity processing. Processors like Undo and NuvPending run a few of these and also run other processes, such as loading the changes that happened during activity processing and reversing those changes.
