Activity API
The Activity API Property Class allows users to link a user-defined routine to an Activity or Activity Class. As per AA framework, when a version is attached to ACTIVITY.PRESENTATION, no routines attached at the version level are executed. Activity API serves as the link where we can attach the user-defined routines for various stages of execution for different Activity or Activity Class. Read Processing API Routines for more details.
ACTIVITY.API is a cumulative Property. This implies that when a child and its parent product have routines defined for the same Activity or Activity Class, then the routines defined at both levels get executed.
An Activity might comprise of one or more ACTION.ACTIVITY.API that provides high level of flexibility by allowing the user to attach user-defined routines based on Actions.
Product Lines
The following Product Lines use the Activity API Property Class:
- Accounts
- Agent
- Bundle
- Deposits
- Facility
- Internet Services
- Lending
- Proxy Services
- Relationship Pricing
- Rewards
- Safe Deposit Box
Property Product Relationship
The Activity API Property Class uses the following Property Class Types:
- Dated
- External
- External.Financial
- Enabled For Memo
- Merge
- Tracking.Only
Defining the Activity API at Product Level
The user needs to specify the Activity or Activity Class for which a user-defined routine has to be executed along with the Property or Property Class. As the same Action can be used in multiple activities, thus mentioning the Action for every Activity or Activity Class definition is mandatory.
The user-defined routines have to be defined in EB.API.
Processing API Routines
As the ACTIVITY.API is of Merging type, while Proof and Publish of the product, the ACTIVITY.API Property follows the below order for merging:
- Routines attached at child product activity level
- Routines attached at parent product activity level
- Routines attached at child product activity class level
- Routines attached at parent product activity class level
Scenario to depict the above order:
Parent Product: MORTGAGE.PARENT
In the Product Condition for Activity API Property Class the details are as below:
- ACTIVITY.1 – Lending-Makedue-Interest
- PROPERTY.1 – Interest
- PRE.VALIDATE.RTN – A1
- ACTIVITY.CLASS.2 - Lending-Makedue-Interest
- PROPERTY.1 – Interest
- PRE.VALIDATE.RTN – B1
Child Product: RETAIL.MORTGAGE
In the Product Condition for Activity API Property Class the details are as below:
- ACTIVITY.1 – Lending-Makedue-Interest
- PROPERTY.1 – Interest
- PRE.VALIDATE.RTN – C1
The order of execution formed in the AA.PRD.CAT file during Proof and Publish is:
- C1-> A1->B1
Activity API provides flexibility to execute a particular routine in different orders during a particular activity execution. During the processing of an Arrangement Activity, Temenos Transact determines whether any routines have to be executed prior to or after any of the Actions. In Activity API, the user can specify five different positions where these routines can get triggered. They are:
- RECORD.RTN: These routines are executed first, after the basic details for an arrangement are provided and the Property level records are built or fetched based on Product Conditions.
- PRE.VALIDATE.RTN: This routine gets invoked before core validation routines. Using this routine, the user can populate or modify the fields and get it ready for core validation.
- VALIDATE.RTN: This gets triggered on validating and committing the record and is executed after the core validations are done.
- PRE.ROUTINE: This routine is executed on committing before the core processing is done.
- POST.ROUTINE: This routine is executed on committing after the core processing is done.
The processing of each arrangement condition records is as follows:
The previous scenario is modified to depict the priority of routines execution along with the merging property.
Parent Product: MORTGAGE.PARENT
In the Product Condition for Activity API Property Class the details are as below:
- ACTIVITY.1 – Lending-Makedue-Interest
- PROPERTY.1 – Interest
- RECORD.RTN – A1
- PRE.VALIDATE.RTN – A2
- VALIDATE.RTN – A3
- POST.ROUTINE – A4
- ACTIVITY.CLASS.2 - Lending-Makedue-Interest
- PROPERTY.1 – Interest
- RECORD.RTN – B1
- PRE.VALIDATE.RTN – B2
- VALIDATE.RTN – B3
- PRE.ROUTINE – B4
Child Product: RETAIL.MORTGAGE
In the Product Condition for Activity API Property Class the details are as below:
- ACTIVITY.1 – Lending-Makedue-Interest
- PROPERTY.1 – Interest
- RECORD.RTN – C1
- PRE.VALIDATE.RTN – C2
- VALIDATE.RTN – C3
- PRE.ROUTINE – C4
The order of execution formed in the AA.PRD.CAT file during Proof and Publish is:
- C1-> A1->B1->C2->A2->B2->C3->A3->B3->C4->B4->A4
The routines have to be called each time an activity is done and the Arrangement Property to which the routine is attached, is in input mode.
Add Activity API Property to Existing Arrangements
The financial institutions can add the Activity API property to the existing arrangements of the Accounts, Deposits, Lending, and Multi-Currency Accounts product lines using the Add New Property, New Prop Avl, and New Prop Avl Date fields in AA.PRODUCT.MANAGER.
Read Add New Property for more information on the configuration.
Periodic Attribute Classes
There are no periodic attribute classes for the Activity API Property Class.
Action
The Activity API Property Class supports the following actions:
| Action Name | Description |
|---|---|
| UPDATE | Allows the user to change any of the ACTIVITY.API attributes. This action can be initiated as part of the NEW-ARRANGEMENT and UPDATE-ACTIVITY.API Activities and results in modification of the API rules. |
Accounting Events
The ACTIVITY.API Property does not perform any actions that generate accounting events.
Limits Interaction
The ACTIVITY.API Property does not perform any actions that impact on the limits system.
In this topic