Task Registration:

Every new service to be integrated as a part of OBAPI needs to provide a task code. This task code is required while integrating the

service with various infrastructural aspects applicable to the service. Few examples of infrastructural aspects or cross cutting

concerns provided out of the box with OBAPI are:

• Limits
• Approvals
• Two Factor Authentication
• Transaction Blackout
• Working Window
• Account Relationship

Guidelines for formulating a task code are as follows:

A task code should ideally comprise of three parts:

1. Module Name : The first 2 alphabets representing the module to which the service in question belongs. e.g TD represents Term Deposits module.
2. Task Type(type of service) : OBAPI supports the following 6 types of services.
   1. FINANCIAL_TRANSACTION(F) : Any transaction as a result of which there is a change in the status of the finances of accounts of the participating parties. In general any transaction that involves monetary transfer between parties via their accounts. Few examples include Self transfer, New deposit(Open term deposit), Bill payment etc.
   2. NONFINANCIAL_TRANSACTION(N) : Any transaction that pertains to an account but there is no monetary payment or transfer involved in it. For example Cheque book request.
   3. INQUIRY(I) : Any read only transaction supported in OBAPI that does not manipulate any business domain of the financial institution. For example list debit cards, read loan repayment details, fetch term deposit penalties etc.
   4. ADMINISTRATION(A) : Transactions performed by bank admins and corporate admins for a party come under this category. Few examples of such transactions include limit definition, limit package definition, user creation, rule creation and various others.
   5. MAINTENANCE(M) : Maintenances done by a party for itself fall under this category. Maintenance transactions performed by a non admin user which does not involve any account or monetary transaction comprise of this transaction type. Example add biller.
   6. COMMON(C) : Common transactions include transactions which do not fall under any of the above mentioned categorization. Example login.

      So 1 alphbet F,N,I,A,M or C for each of the above mentioned task types respectively forms the second part of the task code.

3. Abbreviation for service name : A 3 to 10 lettered abbreviation for the service name. Example OTD for Open Term Deposit. All the above mentioned three parts are delimited by an underscore character.

   Example : TD_F_OTD where TD represents module name. F represents that its a financial transaction i.e. task type and OTD is the abbreviated form of the transaction(service) name.

Task Aspects:

An ‘aspect’ of a task is a behavior or feature supported by the task. OBAPI framework defines a set of aspects that can be supported by a task in the system. These aspects need to be configured in table DIGX_CM_TASK_ASPECTS. So if a task supports given aspect, then only its entry should be made in this table. If for any task, entry does not exist in this table for given aspect, then system treats it as that aspect is not supported by the task.

Additionally an aspect can be temporarily disabled using the ‘ENABLED’ column of this table. If the ‘ENABLED’ value is set as ‘N’, then system will treat it as this aspect is not supported by the task. Note that if a task is never going to support an aspect, then its entry should not be there in DIGX_CM_TASK_ASPECTS table. The ‘ENABLED’=’N’ option for disabling aspect should be used only when the task generally supports the aspect but it needs to be disabled for small duration.

Note that just having an entry in this table does not imply that the feature will be enabled for the task. The entry in this table only tells that system that the task supports this feature. Individual feature might need further configurations for them to work properly.

List of aspects supported by OBAPI framework is listed below. Please note that aspects are not extensible – in other words it is not possible to add new aspects as part of customization.

Steps to register a task with OBAPI:

1. The task code needs to be configured in the database table DIGX_CM_TASK. For example if we consider Open Term Deposit then the below:

   query fulfills the requirement mentioned in this step.

   Insert into DIGX_CM_TASK 
   (ID, NAME, PARENT_ID,EXECUTABLE, TASK_TYPE, MODULE_TYPE, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY,
   LAST_UPDATED_DATE, OBJECT_STATUS, OBJECT_VERSION_NUMBER) values ('TD_F_OTD', 'New Deposit',
    'TD_F', 'Y', 'FINANCIAL_TRANSACTION', 'TD', 'ofssuser', sysdate, 'ofssuser', sysdate, null,1);

   As evident from the above query example Tasks have a hierarchy. Every task might have a parent task denoted by the task code value held by the PARENT_ID column of DIGX_CM_TASK. In most of the cases its a 3 level hierarchy.

   • Leaf level tasks to which services are mapped at the lowest level
   • Task representing the module to which the service belongs at the mid level
   • Task representing the task type at the root level

   For instance consider the task code AP_N_CUG which represents the Usergroup creation service under module approvals(AP). So the PARENT_ID column of task AP_N_CUG(leaf level task) has task code as AP(mid level task). If we look at the entry for task code AP(mid level task) then the value in the PARENT_ID column of DIGX_CM_TASK has MT(root level task) which is the task code representing task type ADMINISTRATION. The leaf level task has 'Y' as the value in its EXECUTABLE column. The mid level and root level tasks have 'N' as the value in its EXECUTABLE column.

2. Configure aspects supported by the task. For example, if above task supports blackout, approval and working window, then following entries should be made.

   Insert into DIGX_CM_TASK_ASPECTS (TASK_ID,ASPECT,ENABLED)
   values ('TD_F_OTD','approval','Y'); 
   
   Insert into DIGX_CM_TASK_ASPECTS (TASK_ID,ASPECT,ENABLED)
   values ('TD_F_OTD','working-window','Y'); 
   
   Insert into DIGX_CM_TASK_ASPECTS (TASK_ID,ASPECT,ENABLED)
   values ('TD_F_OTD','blackout','Y');

3. Register the newly created service against this task.

   For this step firstly, you need to get the service id for your service(transaction). Service id is the fully qualified name of the class appended by the dot character (.) and the method name. For example taking open term deposit into consideration, the business logic for the service is encapsulated in the method named create of the service class com.ofss.digx.app.td .service.account.core.TermDeposit.

   Hence the service id is derived as : com.ofss.digx.app.td.service.account.core.TermDeposit.create

   Secondly the below query fulfills the requirement mentioned in this step.

   insert into DIGX_CM_RESOURCE_TASK_REL 
   (ID, RESOURCE_NAME, TASK_ID, CREATED_BY,CREATION_DATE, LAST_UPDATED_BY, 
   LAST_UPDATED_DATE, OBJECT_STATUS, OBJECT_VERSION_NUMBER) 
   values ('1', 'com.ofss.digx.app.td.service.account.core.TermDeposit.create', 
   'TD_F_OTD','ofssuser', sysdate, 'ofssuser', sysdate, null,1);

   The aforesaid procedure enrolls your newly created service as a task in OBAPI.

Managing Task Aspects for Custom Requirements

Out of the Box behaviour:

Every DML service in OBAPI application is associated with a Task. A Task in obapi can be associated to one or more Task Aspects like Approval, Limits, Two Factor Authentication etc.

Probable Requirement: In a special scenario while invoking a service a financial institution might want to toggle a task aspect for a task.

For such requirements we provide a configuration called taskEvaluatorFactories. This config can be checked in the application using below query.

For such requirements we provide a TaskEvaluatorFactory which is mapped to Tasks based on the “@TargetTask” in“@TargetTasks” annotationAnnotations needed to create a TaskEvaluatorFactory

1. Every custom TaskEvaluatorFactory must have @Custom annotation signifying it as a customization from vendor.
2. Every TaskEvaluatorFactory must have a no-args default constructor.
3. Every TaskEvaluatorFactory is configured against a TASK_ID’s using @TargetTasks annotation which hold the @TargetTask. If the @Base TaskEvaluatorFactory and @Custom TaskEvaluatorFactor target the same task then for that task the base TaskEvaluatorFactory will be overridden and suppressed by the Custom TaskEvaluatorFactory.
4. The fully qualified name of every new TaskEvaluatorFactory must be added in new line of . META-INF/services/com.ofss.digx.framework

Every TaskEvaluatorfactory class configured here implements the below interface:

com.ofss.digx.framework.task.evaluator.ITaskEvaluatorFactory

which has the below method declaration

public ITaskEvaluator getEvaluator(TaskAspect taskAspect);

Inputs: TaskAspect for which the default behaviour is needed to be changed. For example if TaskAspect approvals need to be toggled then only that evaluator can be implemented and its instance can be returned. Rest all TaskAspects can continue using their default evaluators.

Output: Implementation of class ITaskEvaluator explained below.

that means TaskEvaluatorFactory takes a Task Aspect as an input and returns a TaskEvaluator.Every TaskEvaluator is a class that implements the ITaskEvaluator

which has the below method declaration

public String evaluateTaskCode(String taskCode, 
List<Object> serviceInputs) throws Exception;

Inputs: taskCode - the current task code configured in the system as per the service invoked.

serviceInputs - the arguments passed to the first service called from rest. These arguments help in deducing the logic whether the special condition is met or not in which we wish to toggle the TaskAspect.

Output: String that is a new TaskCode(not the one passed as an input) for which we have configured the TaskAspect in a way different than the default taskcode(the one passed as an input to evaluateTaskCode).

Let us consider an example of. A TaskEvaluatorFactory:PeerToPeerPaymentTaskEvaluatorFactory is an implementation of Task Evaluator Factory which will be used for Task PC_F_CPTP, PC_F_PTP, this is avalaible in the base product.

Overriding existing Task evaluator factory for a particular task

This can be done by just creating a custom class and adding @TargetTask with taskId of the taskfor which the Task Evaluator Factory needs to be overridden , this will suppress the @Base Task evaluator factory implementation The use case for this could be to change the existing functionality of the TaskEvaluator Factory .

Let us create custom Task Evauluator Factory

CustomPeerToPeerPaymentTaskEvaluatorFactory which will override existing PeerToPeerPaymentTaskEvaluatorFactory for taskId PC_F_CPTP.

So when TaskEvaluatorFactory is required for taskId “PC_F_CPTP” the CustomPeerToPeerPaymentTaskEvaluatorFactory will be loaded.

Hypothetical Sample Requirement:

OBAPI application should not ask for the configured 2nd Factor Authentication in case of payments made for less than a pre-configured amount.

Process:

1. insert a new TaskCode in the application by making an entry in the table digx_cm_task.
2. configure the TaskAspects for this new task such that 2fa is disabled by making appropriate entries in the table digx_cm_task_aspects.
3. Write a TaskEvaluator as mentioned above such that with the help of serviceInputs it figures out that the amount getting transfered in this payment is less than pre-configured amount and hence returns the Task Code created in Step 1. If the amount is greater than the pre-configured amount, then it returns the task code passed as an input.
4. Write a TaskEvaluatorFactory as explained above. This new TaskEvaluatorFactory can extend the preconfigured(default) TaskEvalutorFactory such that for TaskAspects other than TWO_FACTOR_AUTHENTICATION it can return same TaskEvaluator as the preconfigured TaskEvalutorFactory. For TaskAspect TWO_FACTOR_AUTHENTICATION it returns the newly created TaskEvaluator written in Step 3.
5. Register fully qualified name of this TaskEvalutorFactory.in META-INF/services/com.ofss.digx.framework.task.evaluator.ITaskEvaluatorFactory file.

Limit Configuration

The below procedure describes the steps required to enable Limits for a newly developed service.

A prerequisite to this configuration is that this newly developed service should be registered as a task in OBAPI. Refer “Task Registration” section for further details.

The types of Limits supported by the system are:

• Periodic Limit(Cumulative) : Limits that get reset after the expiration of a period. Example Daily-limits.
• Duration Limit(Cooling Period): Limits that get applicable after the occurrence of an event, for instance payee creation, and then are applicable for the specified duration after commencement of the event.
• Transaction Limit : Limits applicable to each invocation of a transaction. Holds minimum and maximum amount that can be transacted in a single transaction invocation.

Limits are applicable to targets. The types of targets supported by OBAPI are Task and Payee.

• Task : Any service developed as a part of OBAPI and registered as a task as mentioned in earlier sections
• Payee : A payee resource created via Payee creation transaction in OBAPI.

To enable limits for a service, rather for a task mapped to the service to be precise, we need to follow the below mentioned steps:

1. Ensure that the ‘limit’ aspect is configured in DIGX_CM_TASK_ASPECTS table and ENABLED column is updated as 'Y' for your task id.
2. Register taskEvaluatorFactory for your task code. Please refer the above steps for registering a taskEvalautorFactory.

   Code a LimitDataEvaluator for the task. LimitDataEvaluator is a class that extends AbstractLimitDataEvaluator class present in com.ofss.digx.finlimit.core.jar. This class is an abstract class which has only 1 abstract method having signature as shown below:

   /** * provide {@link AbstractAspectData} of
             currently executing task. * * @param serviceInputs *            
   the service inputs * @return {@link AbstractAspectData} required
             for limit utilization and validation * @throws Exception 
   */public T evaluate(List<Object> serviceParameters) throws Exception

   This method receives a List<Object> as an input. This list has all the arguments that were passed to the newly coded service for which limits needs to be enabled. For instance, consider the service to open a termed deposit. Signature of the service is as shown below.

   public TermDepositAccountResponseDTO create(SessionContext sessionContext,
             TermDepositAccountDTO termDepositAccountDTO) throws Exception

   In this case when the LimitDataEvaluator coded for open term deposit task i.e. TD_F_OTD is invoked by the OBAPI framework, the serviceInputs argument of evaluate method will contain 2 objects in the list namely SessionContext and TermDepositAccountDTO. The return type of evaluate method is LimitData. The state of a LimitData object comprises of three variables:

   • CurrencyAmount : an Object of type CurrencyAmount which represents the monetary amount involved in the ongoing transaction along with the currency in the transfer or payment is made.
   • payee : An object of type PayeeDTO. Needs to be populated in case a payee is involved in the transaction.
   • limitTypesToBeValidated : A list of LimitTypes. For all unexceptional practical purposes this needs to be populated as shown below:

     limitTypesToBeValidated = new ArrayList<LimitType>(Arrays.asList
     (LimitType.PERIODIC,LimitType.DURATION,LimitType.TRANSACTION));

     These 3 fields in case applicable needs to be derived from the argument serviceInputs and populated in the returned LimitData object.

• Register the LimitDataEvaluator coded in Step 3.
• Every LimitDataEvaluator(AspectDataEvaluator) must have @Custom annotation signifying it as a customization from vendor.
• Every LimitDataEvaluator(AspectDataEvaluator) must have a no-args default constructor
• Every LimitDataEvaluator is configured against TASK_ID’s using @TargetTasks annotation which hold the @TargetTask. If the @Base LimitDataEvaluator and @Custom LimitDataEvaluator target the same task and the supportedAspects are the same then for that task the @Base LimitDataEvaluator will be overridden and suppressed by the @Custom LimitDataEvaluator.
• The fully qualified name of every new TaskEvaluatorFactory must be added in new line of META-INF\services\com.ofss.digx.framework.evaluator.data.IAspectDataEvaluator file.

1. Code a TargetEvaluator for your task.

   Note:

   This step is needed only if your task requires limits involving Payees. Example Duration Limits and payee limits.

   Payee limits are Periodic and Transactional limits applied on a Payee. TargetEvaluator is a class that implements ITargetEvaluator interface.

   TargetEvaluator is a functional interface that has only 1 method as shown below :

   /** * Evaluates the Target details for the given evaluated task code and service
   inputs in the form of * {@link TargetDTO}. *  
   * @param evaluatedTaskCode * the given evaluated task code * @param serviceInputs *
   inputs of the service using this evaluator * @return target details of the target for
   this task code and service inputs in the form of {@link TargetDTO}. 
   * @throws Exception * exception while evaluating {@link TargetDTO} */ 
    public TargetDTO evaluate(String evaluatedTaskCode, List<Object> serviceInputs) throws
   Exception;

   This method accepts the task code and serviceInputs in case something needs to be derived from the arguments passed to the service.

   It returns a TargetDTO. TargetDTO has an id, name, value and TargetTypeDTO. TargetType tells whether the target is of type task or payee.

   If the TargetType is TASK then the variable value of TargetDTO holds the task code for the service.If the TargetType is PAYEE then the variable value of TargetDTO holds the payeeId of the payee involved in the service.

   As this step is required only for limits pertaining to payees so TargetType will be PAYEE and targetDTO's value will be payeeId.

2. Register the TargetEvaluator coded in Step 4.

   Note:

   This step is needed only if your task requires limits involving Payees. Example Duration Limits and payee limts.

   Payee limits are Periodic and Transactional limits applied on a Payee.

   This needs an insert in DIGX_FL_TARGET_EVALUATOR table as shown below:

   Insert into DIGX_FL_TARGET_EVALUATOR 
   (TASK_CODE, TARGET_TYPE, EVALUATOR, PROP_COMMENTS, SUMMARY_TEXT, CREATED_BY, 
    CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATED_DATE, OBJECT_STATUS,
   OBJECT_VERSION_NUMBER) values (<<task code>>, 'PAYEE', <<TargetEvaluator>>,
   null, 'target evaluator for <<service name>> service', 'ofssuser', sysdate,
   'ofssuser', sysdate, 'Y', 1);   

   In the above query <<task code>> is the task code for the service, <<TargetEvaluator>> is the fully qualified name of the

   class coded in Step 4. <<service name>> is a descriptive name for the service.

   The aforesaid procedure enables limits for a task in OBAPI.

Approval Configuration

The below procedure describes the steps required to enable Approvals for a newly developed service.

A prequisite to this configuration is that this newly developed service should be registered as a task in OBAPI. Refer “Task Registration” section for further details.

To enable approvals for a service, rather for a task mapped to the service to be precise, we need to follow the below mentioned steps:

• Ensure that the ‘approval’ aspect is configured in DIGX_CM_TASK_ASPECTS table and ENABLED column is set to ‘Y’ for your task id.

  Note:

  If the newly created task is of type ADMINISTRATION and the maintenance is not specific to a party then this step is not required. Examples of such transaction are 2 Factor Authentication maintenance, limit maintenance and limit package maintenance. Tasks of type ADMINISTRATION which are specific to a party like Rule management tasks, workflow management tasks etc require this step.

  Tasks of type FINANCIAL_TRANSACTION,NONFINANCIAL_TRANSACTION,MAINTENANCE,INQUIRY and COMMON require this step.

  Code an approval assembler for the new task. An approval assembler is a class that extends AbstractApprovalAssembler.

Steps to Code an approval assembler for the new task. Annotations that are used are as follows:

1. An approval assembler is a class that extends AbstractApprovalAssembler.
2. The new Approval Assembler class should contain @Custom annotation. The @Custom annotation is used to denote that the Approval assembler is customization from vendor.
3. It must also contain @TargetServices which contains @TargetService, mapping the approval assembler to different services The @TargetServices annotation holds different @TargetService that hold serviceID of a service.If a @Custom Assembler targets a service similar to the @Base Assembler then the @Custom assembler will override the @Base assembler for that service.
4. The new Approval Assembler must have a no-args default constructor.
5. For every new Approval assembler anEntry in META-INF\services\com.ofss.digx.framework.domain.transaction.assembler.AbstractApprovalAssembler is mandatory.

There are 4 methods in abstract approval assembler out of which the one with the below signature:

public abstract T toDomainObject(D requestDTO) throws Exception;

will encapsulate the logic required to populate Transaction domain which is used by approvals framework.

Rest of the methods need to be overridden with empty or null implementations.

As evident from the signature quoted above this method accepts a requestDTO(an object that IS A DataTransferObject) and a transaction(an object that IS A Transaction).

requestDTO is the same DataTransferObject that was passed to your newly created service. For instance consider the service to open a termed deposit. Signature of the service is as shown below.

public TermDepositAccountResponseDTO 
create(SessionContext sessionContext,
TermDepositAccountDTO termDepositAccountDTO) throws Exception

In this case when the ApprovalAssembler coded for open term deposit task i.e. TD_F_OTD is invoked by the OBAPI framework, the requestDTO argument of toDomainObject method will be the same as termDepositAccountDTO.

This method populates the transaction object on the basis of the requestDTO and returns the transaction domain. The guidelinesto override this method are as follows:

• Instantiation:

  The transaction object passed will be null and needs to be instantiated. If the task type of the newly created service is FINANCIAL_TRANSACTION then the transaction needs to be instantiated as an object of AmountAccountTransaction.

  transaction = new AmountAccountTransaction();

  If the task type of the newly created service is NONFINANCIAL_TRANSACTION then the transaction needs to be instantiated as an object of AccountTransaction.

  transaction = new AccountTransaction();

  If the task type of the newly created service is MAINTENANCE then the transaction needs to be instantiated as an object of PartyTransaction.

  transaction = new PartyTransaction();

  If the task is of type ADMINISTRATION and the maintenance is not specific to a party then the transaction needs to be instantiated as an object of Transaction.

  transaction = new Transaction();
• Callto AbstractApprovalAssembler :

  Call transaction = super.toDomainObject(requestDTO, transaction);

  This populates the generic state of transaction domain which does not change with the task for which approvals is being configured. c. Populate the state of the transaction domain which is specific to the task for which approvals is being configured. Cast the requestDTO to the type being accepted by the service. For example cast it to TermDepositAccountDTO as per the aforesaid example. Use this DTO to populate the service specific state of the transaction domain like amount, account etc.

• If the newly created task is of type ADMINISTRATION and the maintenance is not specific to a party then the approval assembler to be registered against your service is om.ofss.digx.framework.domain.transaction.assembler.GenericDTOTransactionAssembler 2 Factor Authentication Maintenance is a fine example of such transactions. The service id for this transaction is com.ofss.digx.app.security.service.authentication.maintenance. AuthenticationMaintenance.

  Create a new approval assembler and extend the existing com.ofss.digx.framework.domain.transaction.assembler.GenericDTOTransactionAssembler and map this approval assembler to your required service. This will cause the new assembler to inherit all the methods of the GenericDTOTransactionAssembler.

  
  
  
  Description of the illustration taskconfig3.png
  
  

  It must have no-args default constructor and and entry must be made in META-INF\services\com.ofss.digx.framework.domain.transaction.assembler.AbstractApprovalAssembler

  Lets us understand how to override the approval assemblers

  Suppose we want to customize the assembler for "com.ofss.digx.app.approval.service.usergroup.UserGroup.create" service which uses UserGroupTransactionAssembler as seen below.

  UserGroupTransactionAssembler

  
  
  
  Description of the illustration taskconfig4.png
  
  

  Create a new assembler “UserGroupCustomTransactionAssembler” that extends the AbstractApprovalAssembler and give it the @Custom Annotation to indicate it as a customization , also if @Custom Assembler targets a service which is also a Target of @Base Assembler then for that particular service the @Custom assembler will override the @Base Assembler

  
  
  
  Description of the illustration taskconfig5.png
  
  

  Also respective entries for the new UserGroupCustomTransactionAssembler needs to be made in META-INF/services/com.ofss.digx.framework.domain.transaction.assembler.AbstractApprovalAssembler

  The aforesaid procedure enables approvals for a task in OBAPI.

Account Relationship

Using this aspect, one can control accounts for a transaction.

1. Account Number List Filtration

   To filter the account list based on Account Relationship configuration, task code should be provided in REST call in following manner

   ../digx/v1/accounts/demandDeposit?taskCode=TD_F_OTD

   Above REST will return only allowed accounts for ‘New Deposit’ transaction.

2. Account Number Validation

   Here we validate account number(s) using Account Relationship Configuration.

   Following changes need to be done to achieve this

   Evaluator class – If ‘Account Relationship Check’ is enabled for a transaction, then application looks for registered evaluator class. This class is used to identify account number(s) from incoming request object and converts it into input which is required for account relationship checking.

   Evaluator class should implement interface

   ‘com.ofss.digx.app.accountrelationship.evaluator.mapping.IAccountRelationshipDataEvaluator’

   Annotations needed to create a AccountRelationshipEvaluator

   Annotations	Description
   @Custom	The @Custom Annotation signifies that the business policy is customization from the vendor, this is mandatory for every new business policy created by the vendor.
   @TargetTasks	The @TargetTasks annotation must include all the @TargetTask that the business policy needs to target.
   @TargetTask	Each TargetTask must include a TaskCode(String) specifying the task intended for the current Business Policy.

1. Every custom AccountRelationshipEvaluator must have @Custom annotation signifying it as a customization from vendor.
2. Every AccountRelationshipEvaluator must have a no-args default constructor.
3. Every TaskEvaluatorFactory is configured against TASK_ID’s using @TargetTasks annotation which hold the @TargetTask. If the @Base AccountRelationshipEvaluator and @Custom AccountRelationshipEvaluator target the same task then for that task the base AccountRelationshipEvaluator will be overridden and suppressed by the Custom AccountRelationshipEvaluator.
4. The fully qualified name of every new AccountRelationshipEvaluator must be added in new line of META-INF/services/com.ofss.digx.app.accountrelationship.evaluator.mapping.IAccountRelationshipDataEvaluator file.

Example - ‘com.ofss.digx.app.td.evaluator.accountrelationship.TDAccountRelationshipEvaluator’ is an evaluator class which is used for ‘New Deposit’ transaction.

Inside ‘evaluate’ method of this class, account number from request object ‘com.ofss.digx.app.td.dto.account.TermDepositAccountDTO’ is being get converted into list of ‘com.ofss.digx.app.party.dto.relation.account.PartyToAccountRelationshipDTO’.

Also respective entries of name of the evaluator needs to be made in META-INF/services/com.ofss.digx.app.accountrelationship.evaluator.mapping.IAccountRelationshipDataEvaluator file.

This will register TDAccountRelationshipEvaluator for the task “TD_F_OTD”

Note that if there is a @Base(comes with base product) evaluator that targets the same task “TD_F_OTD” the above @Custom evaluator will override it.

Date Evaluators

They are used to get the date depending on the TaskCode. This could be used in scenarios where a different date evaluator implementation is required for different TaskCode as current date is specific to the transaction being performed.

eg: For transactions(such as international transfer) where third party hosts are used , different date evaluators can be used to get the current date from respective host.

Annotations needed to create a DateEvaluator

1. Every custom DateEvaluator must have @Custom annotation signifying it as a customization from vendor.
2. Every DateEvaluator must have a no-args default constructor.
3. Every DateEvaluator is configured against TASK_ID’s using @TargetTasks annotation which hold the @TargetTask. If the @Base DateEvaluator and @Custom DateEvaluator target the same task then for that task the base DateEvaluator will be overridden and suppressed by the Custom DateEvaluator.
4. The fully qualified name of every new DateEvaluator must be added in new line of META-INF/services/com.ofss.digx.app.date.evaluator.AbstractDateEvaluator file
5. Every DateEvaluator must extend com.ofss.digx.app.date.evaluator.AbstractDateEvaluator;