Skip to content

Overridable Methods

The IFS Aurena framework makes extensive use of the concept of overridable methods. The intention is to keep the IFS Aurena client as thin as possible hence, most of the client validations that were introduced in the IFS Enterprise Explorer development is now moved to the server, that is the projection file.

Overridable CRUD ( C reate, R ead, U pdate, D elete) methods are generated based on the available CRUD actions of the entity or virtual. Note: Generated method signatures are a bit different between entities and virtuals.

Structure

The general structure of the overridable CRUD methods are as below:


//Example Code - General Method Structure  
//---------------------------------------  
    @Override  
    PROCEDURE CRUD_Create(  
        etag IN OUT VARCHAR2,  
        key_ IN OUT Fa_Object_Number_Series_Key,  
        attr_ IN OUT VARCHAR2,  
        info_ OUT VARCHAR2 )  
    IS  
    BEGIN  
        --Pre validations and other pre processing actions  
        super(etag_, key_, attr_, info_);  
        --Post Validations and other post processing actions  
    END CRUD_Create_;  

Note: All client validations must be added before the call to super().

List of available overridable methods

  • CRUD_Create___ is called when a new record is inserted.
  • CRUD_Update___ is called when saving a modified record.
  • CRUD_Delete___ is called when deleting a record
  • CRUD_Default___ is called when creating a new record in client. This is essentially a wrapper for the Prepare_Insert___ method. Here we can add values to the attribute string, so that they will show up in the client as default values for the relevant fields. The same can be achieved by using the default property of the attributes in the projection. CRUD_Default___ is really useful when working with master detail pages, where in the detail page you need the parent keys to access some information; in this case the CRUD_Default___ method will pass the relevant values.

Overridable methods in Entities

CRUD_Create___

Following is the method signature for the CRUD_Create___ method:


PROCEDURE CRUD_Create___(  
    etag_ IN OUT VARCHAR2,  
    key_ IN OUT Depr_Hold_Info_Key,  
    attr_ IN OUT VARCHAR2,  
    info_ OUT VARCHAR2 );  

etag_ - The etag parameter is a combination of the objid and objversion. In CRUD_Create the etag is initially etag set to null, but is filled once the call to super() is executed.

key_ - is of record type, where we can access each information with period (.) notation. The key parameter is also initially set to null, gets filled once the call to super() is executed.

CRUD_Update___

Following is the method signature for the CRUD_Update___ method:


PROCEDURE CRUD_Update___(  
    etag_ IN OUT VARCHAR2,  
    key_ IN OUT Depr_Hold_Info_Key,  
    attr_ IN OUT VARCHAR2,  
    info_ OUT VARCHAR2 );  

etag_ - Contains a combination of the objid and objversion values of the record to be updated.

key_ - Contains values that can be access with the period (.) notation.

attr_ - Contains the attribute values that were modified.

CRUD_Delete___

Following is the method signature for the CRUD_Delete___ method:


PROCEDURE CRUD_Delete___(  
    etag_ IN OUT VARCHAR2,  
    key_ IN Depr_Hold_Info_Key,  
    info_ OUT VARCHAR2 );  

etag - Contains a combination of the objid and objversion values of the record to be deleted.

key - Contains values that can be access with the period (.) notation.

CRUD_Default___

CRUD_Default___ method generates two variations; one which has the attribute string as the OUT parameter and the other has a record as the OUT parameter, as shown below:


//Method variation 1 - 'attr_' as the OUT parameter  
PROCEDURE CRUD_Default___(  
    key_ IN Fa_Book_Mapping_Per_Object_Key,  
    attr_ IN OUT VARCHAR2,  
    info_ OUT VARCHAR2);  

//Method variation 2 - 'rec_' as the OUT parameter  
PROCEDURE CRUD_Default___(  
    rec_ IN OUT Fa_Book_Mapping_Per_Object_Rec);  

Below is an example usage of CRUD_Default___:


@Override  
PROCEDURE CRUD_Default___(  
    rec_ IN OUT Income_Type_Rec)  
IS  
    dummy_ NUMBER := -99999;  
BEGIN  
    rec_.internal_income_type := dummy_;  
    super(rec_);  
END CRUD_Default___;  

Overridable methods in Virtuals

As mentioned in the beginning of the document the method signatures for virtuals are bit different compared to the overridable methods in entities. While entities work with the attribute string, virtuals work with records.

CRUD_Create___

Following is the method signature for the CRUD_Create___ method:


PROCEDURE CRUD_Create___(  
    rec_ IN Create_Company_Template_Vir_Rec );  

CRUD_Update___

Following is the method signature for the CRUD_Update___ method:


PROCEDURE CRUD_Update___(  
    old_ IN Create_Company_Template_Vir_Rec,  
    new_ IN Create_Company_Template_Vir_Rec );  

CRUD_Delete___

Following is the method signature for the CRUD_Delete___ method:


PROCEDURE CRUD_Delete___(  
    rec_ IN Create_Company_Template_Vir_Rec );  

Overriding in the client model

At present selectors and LOV (list of value) lists can be overridden in the client model file, since these controls are generated based on the entities, references, and queries that are included in the.projection files.

Overriding Selectors

If we go to the base client file we can see set of selectors which are generated. Any of the selectors in the generated base client file can be overridden in the.client file without the use of the @override annotation, see example below:


// In xxx-Base.client file  
// -----------------------  
selector StateCodes2QuerySelector for StateCodes2Query {  
    label = "${StateCode}";  
    static CountryCode;  
    static StateCode;  
}  

The above code can be overridden in.client file as follows:


selector StateCodes2QuerySelector for StateCodes2Query {  
    label = "${StateCode} - ${StateName}";  
    static CountryCode;  
    static StateCode;  
    static StateName;  
}  

Overriding LOV (List of Values) Lists

You may have already noticed if you click on an LOV in IFS Aurena, it only fetches 3 or 4 attributes, but if you check in IFS Enterprise Explorer the same list may contain lot of columns. This is where LOV lists come into play. In each LOV you have an advanced option that opens up the LOV in a table view, which normally contains more columns than the standard LOV. You can customize this advance mode by overriding the LOV Lists by specifying the @Override annotation. See example below:


// In xxx-Base.client:  
// -------------------  
list StateCodes2QueryLovList for StateCodes2Query {  
    label = "";  
    static CountryCode;  
    static StateCode;  
    static StateName;  
}  


// In .client file:  
// ----------------  
@Override  
list StateCodes2QueryLovList for StateCodes2Query {  
    label = "";  
    static CountryCode;  
    static StateCode;  
    static StateName;  
    static Province;  
    static Temperature;  
}  

Frequently Asked Questions

Q1: How to handle Validate Cancel functionality?

This can be solved by raising an error message using Error_SYS so that the transaction is aborted.

Q2: I have a warning message in the client which has only an OK button. Use Client_SYS.Add_Info instead of the Alert dialog or Warning Toast in the client file.

Q3: I have a warning message in the client which has the OK and Cancel button, clicking OK will continue the flow, clicking Cancel aborts the execution. Use the Client_SYS.Add_Warning method.

Q4: Extracting each and every attribute from the attribute string is cumbersome. Use the below generated methods in the.plsvc file to do the needful:

  • Add_To_Rec_From_Attr - To extract and add attributes to the attribute string.
  • Add_To_Attr_From_Rec - To convert a record back to attributes.