Overview
By introducing this functionality, system addresses the need of write additional or custom requirements for Model classes’ existing functionality. In Many cases, Developer needs to change /override existing logic or want to put additional validation check on some or all Mclasses actions then he/she can use this functionality to customize logic according to client needs.
...
In order to achieve this functionality, we have introduced a new interface (Model Validation). This document is written for developer(s) that helps them to understand the Model Validation interface and how he can write Model Validator class according to their need and where he/she need to register Model Validator class.
Product Version and dependency
This feature is supported by 'Vienna Advantage Framework <5.0.1.0>'
How to Use
Introduction
Before jump to write user defined Model validator class first we need to know a class and interface that are used in or by ModelValidator class.
...
First three Variables are handled in PO class and PO invoke ModelValidationEngine to fire
ModelChanged event to notify registered client’s ModelValidator classes.
The sequence of ModelChanged event is After the BEFORE SAVE/DELETE of Model Class but Before the actual SAVE and DELETE event of Model class.
...
Note: if ModelValidator class return any string message then it is considered as error message.
Implementation
Developer needs to write a Model Validator class in Module or ViennaAdvantage assembly. Keep in mind following points while writing the class
...
Notify when model change happened like new, update and delete actions for additional validation
Notify when doctype action happened like PrepareIt and CompleteIt functions
Option to Bind ModelActions Likes before save/delete and after delete/save and DocActions(completeIt, PrepareIt, VoidIt, ApproveIt) with Option to skip base functionality or not.
The Initialize function is most important block of ModelValidator class where registration is done for a model class for customization. As we discuss above, mainly three types of registration are done here.
...
Type | Handler/Function | Description |
engine.AddModelChange(X_C_Order.Table_Name, this); | public string ModelChange(PO po, int changeType) | Fired When New,Update or delete is happened |
engine.AddDocValidate(X_C_Order.Table_Name, this); | public string DocValidate(PO po, int docTiming) | Fired for Docaction Prepare And complete |
engine.AddModelAction(X_C_Order.Table_Name, this); | public void BindModelAction(PO po) | Inject ModelAction class for Modelactions* |
*ModelAction Class is abstract class that is used by Client specific Model class to write client specific logic with Option to skip base functionality.
...
We will cover all three case one by one with example.
Case 1: Additional Validation on Model change (New,Update,Delete)
...
engine.AddModelChange(X_C_Order.Table_Name, this);
}
}
}
Write Your Validation code in ModelChange Listener
namespace MOTO1.Model{ class MOTO1ModelValidator : ModelValidator {
...
//Logic return ""; }
}
}
}
Case 2: Additional validation/task on before prepare and after complete
...
return ""; }
}
Case 3: Inject ModelAction class to perform required customizable actions in M(Model) Class.
In new class Developer either write all available functions of M(Model) Class or can write one or two functions depends on requirements.
ModelAction is abstract class must inherited by Used defined Model Action class. Following actions are supported by ModelAction.
Sr No | Function Name |
1 | Before Save |
2 | AfterSave |
3 | BeforeDelete |
4 | AfterDelete |
5 | PrepareIt |
6 | CompleteIt |
7 | ApproveIt |
8 | VoidIt |
Will add more DocActions as needed.
First four functions are handled centrally in PO Class but to fire all other docAction type events we need to add some lines in corresponding DocActrions like we did in PrepareIt and Completeit functions in Case 2 but syntax is different. e.g., for PrepareIt function we need to write following lines In PrepareIt function of MOrder Class.
...
All above function has ‘skipBase’ parameter that will enable Developer to skip base/existing functionality in M(Model) Classes to run only customizable logic of ModelActions class. If Developer decide to run base functionality also then ModelActions class logic runs first followed by M(Model class) logic.
...
We need to write a class inherited by ModelActions to change, add or override existing M(Model) class logic.
...
For example, there is sample code for MotoMOrder that implement BeforeSave function/action for MOrder class.
...
namespace MOTO1.Model
{
class MOTO1ModelValidator : ModelValidator
{
.
.
public void Initialize(ModelValidationEngine engine, int ClientId)
{
engine.AddModelAction(X_C_Order.Table_Name, this);
...
So, when a record is inserted or updated then then BeforeSave function written in MotoMOrder class is called by system and customization logic is executed.
...
Developer can write required Action(Model or Doc) to customization the existing logic and have option to skip the base logic of M(Model class) if needs to.
Model Validator Class Binding
Model validator works at client/Tenant level. Model Validator registered for one client cannot work or interferes with other client logics.
...