Home

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
ClosedDefining 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.

ClosedProcessing 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
EXAMPLE:

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.

EXAMPLE:

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.

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.


Bookmark Name Actions
BACK

In this topic

Feedback
x

Are you sure you want to log-off?