Note: This document is recognized for including obsolete content and is due for being updated. IFS/Design and Rational Rose are no longer used in development of IFS Applications 8. IFS Windows Client and IFS Client Developer are not in use.
The purpose of a programming validation model is to enable development of validations, without forcing the developer to write the same validation code several times. All checks and validations in the code should only be made once, and the code should be public and accessible from all parts of the application (i.e. different components). Actually this means that ordinary interface mechanisms should be used as much as possible.
These validation methods are divided into the following parts described below.
| Validation Type | PL/SQL Method |
|---|---|
| Validation of attributes used inside a class | Unpack_Check_Insert___, Unpack_Check_Update___ |
| Validation of fields for direct client response | Separate methods |
| Validation of foreign keys used from other classes | Exist |
| Validation before removing objects from a class | Check_Delete___ |
The following sections will describe the different validation types above, how they work and how they are integrated in the Foundation1 development environment.
The validations described in the LU base methods is that the validation is implemented close to the unpacking of the client attribute string (attr_). The main reason is to get performance benefits when using these interface from client side. This is made by sending as few attributes as possible when modifying data (only the edited ones are sent by IFS/Client).
Internal LU-validation is made when using the private methods New__ or Modify__. This results in calls to the two implementation methods Unpack_Check_Insert___ and Unpack_Check_Update___.
The client is also able to use method New__ with option 'CHECK' to make the validation part without inserting any rows in the database. This option solves situations with error messages, without performing rollback on any transactions, when the client saves information to the database.
Another type of validation is to decide whether a specific base data value exists within its corresponding logical unit (typical foreign key reference). The standard method supplied by the base methods is named Exist. The method is public and therefore accessible from all other logical units. The service is implemented as a stored procedure with the foreign key as input parameters and the procedure does not produce any output values. The algorithm is as below:
It will be possible to handle the error in the calling procedure by using exception entries for that specific error (see error handling), but the normal case is to let the client handle the error messages. See the section on error handling for more information. See also the system service Error_SYS in the section describing public interfaces.
A problem may occur if complex registration forms always get stuck while getting several error messages, but only one at a time. It is important to state that this will probably not happen too often, because the input parameter to the method Exist is already validated in the client by the following facilities:
An example below describes how one business component interacts with another by calling method Exist in other business classes. Note that these procedure calls are automatically generated through IFS/Design when object references are being made in the object model.
In other terms these validations are typical foreign key validations to ensure the database consistency before the row is inserted in the database.
PROCEDURE Unpack_Check_Insert___ ( attr_ IN OUT VARCHAR2, newrec_ IN OUT &VIEW%ROWTYPE ) IS ptr_ NUMBER; name_ VARCHAR2(30); value_ VARCHAR2(2000); BEGIN ptr_ := NULL; WHILE (Client_SYS.Get_Next_From_Attr(attr_, ptr_, name_, value_)) LOOP IF (name_ = 'PROJ_NO') THEN newrec_.proj_no := value_; ELSIF (name_ = 'DESCRIPTION') THEN newrec_.description := value_; ELSIF (name_ = 'PRIORITY') THEN newrec_.priority := value_; Priority_API.Exist(newrec_.priority); ELSIF (name_ = 'MAXPRICE') THEN newrec_.maxprice := Client_SYS.Attr_Value_To_Number(value_); ELSIF (name_ = 'STA_DATE') THEN newrec_.sta_date := Client_SYS.Attr_Value_To_Date(value_); ELSIF (name_ = 'STATUS') THEN newrec_.status := value_; ProjectStatus_API.Exist(newrec_.status); ELSIF (name_ = 'COMMENTS') THEN newrec_.comments := value_; ELSE Error_SYS.Item_Not_Exist(lu_name_, name_, value_); END IF; END LOOP; Client_SYS.Clear_Attr(attr_); Error_SYS.Check_Not_Null(lu_name_, 'PROJ_NO', newrec_.proj_no); Error_SYS.Check_Not_Null(lu_name_, 'DESC', newrec_.desc); Error_SYS.Check_Not_Null(lu_name_, 'PRIORITY', newrec_.priority); Error_SYS.Check_Not_Null(lu_name_, 'STA_DATE', newrec_.sta_date); Error_SYS.Check_Not_Null(lu_name_, 'STATUS', newrec_.status); EXCEPTION WHEN VALUE_ERROR THEN Error_SYS.Item_Format(lu_name_, name_, value_); END Unpack_Check_Insert___;
One typical issue in development of business applications is to decide whether it is possible to remove a LU-instance and how the LU will know about references from other LUs. An example is how to decide if a specified customer can be removed or not. In this case, a customer may be removed if it has no unpaid customer invoices and that the customer status is "passive".
The procedure Check_Delete___ within the base methods has four separate purposes:
The different problems are described in separate sections below.
The attribute check is made by adding code to the implementation procedure Check_Delete___ which will include object business rules and other application logic such as combination controls. Complex code should be placed in a separate procedure for this purpose, e.g. Check_Delete_Attr___. Typical examples are checks of common attributes such as status codes or date intervals.
The easiest way to solve the problem with existing foreign keys, is to use the REF-flag to use the standard solution of the problem through the system service Reference_SYS. This automatically implies server reference checks of foreign keys when trying to delete information from the database. For more details see option RESTRICTED on object references.
To solve the problem with foreign key attributes, the requirements on the system increase and this means that the "deciding code" must be put in another place where all needed information is available. There is an option to the REF-flag to supply the names of the methods to be executed for user-defined restricted delete control. See options CUSTOM and CUSTOMLIST on object references.
Those options contain a validation part and a delete part and are similar to the standard restricted delete option (RESTRICTED) above. The difference is that CUSTOM and CUSTOMLIST options require the business logic code to be written manually.
To solve the problem with cascade operations, the information within the LU-dictionary will be used to check the planned cascade functions to be used. This solution is implemented by using recursion techniques within PL/SQL and is described in the section for REF-flags (see option CASCADE on object references).
This option is intended to be used for aggregate associations between logical units.