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.
A logical unit contains generated methods, base methods and user defined methods. The section describes each type of method in detail.
Only minor adjustments are recommended for generated methods. The database objects must be reloaded whenever the model is changed. The description of base methods explains the functionality in these methods. They can be called from user defined methods. They should be used to perform standard operations.
The service to create a record is called DO and is placed inside the NEW-method. Before the actual INSERT-statement is executed, the logical unit must ensure that all keys and attributes of the record are valid. Therefore, there must be a separate service to ensure this and, which is called CHECK. This service is combined with the unpacking service for client attribute strings (see below). In an end-user environment it is also required that default values can be fetched from the server. This service is called PREPARE.
| Action | Implementation procedure |
|---|---|
| DO | Insert___ |
| CHECK | Unpack_Check_Insert___ |
| PREPARE | Prepare_Insert___ |
The service to modify a record is called DO and is placed inside the MODIFY-method. Before the actual UPDATE-statement is executed, the logical unit must ensure that all keys and attributes that are sent to the server may be modified and that the values are valid. This service is combined with the unpacking service of client attribute strings (see below) and is called CHECK.
| Action | Implementation procedure |
|---|---|
| DO | Update___ |
| CHECK | Unpack_Check_Update___ |
The service to remove a record is called DO and is placed inside the REMOVE-method. Before the actual DELETE-statement is executed, the logical unit must ensure that the object may be removed and that the specified object isn't used by another LU. This is a difficult problem to solve and is called CHECK.
| Action | Implementation procedure |
|---|---|
| DO | Delete___ |
| CHECK | Check_Delete___ |
The service to lock a record is used by the services MODIFY and REMOVE above (implementation calls). In special cases, the lock service must be called from the client, and therefore the LOCK-service is also implemented as a private service in the templates, but this is not used from the class library as default. The actual code of the locking statement (SELECT FOR UPDATE) is placed in the implementation method Lock___ and may therefore be called from all other methods, including MODIFY and REMOVE.
All methods defined in Rational Rose will also be public methods in the IFS/Design tool. The public methods will be generated as Procedures ( no return data type in the category file) or Functions (return type Number, String or Date in the category file). To edit the code focus the right window and select Edit in the pop-up menu options.
The following definitions of public methods exist in the template file:
| Code | Description |
|---|---|
|
The body for functions includes &NAME which will be translated into the name of the method. The &KEYARG will be translated into attributes with the same name and type as in the main view. You have to add PL/SQL code according to PL/SQL guidelines between BEGIN
and END. The return data type must be the same as in the category file. |
|
The body for procedures includes &NAME which will be translated into the
name of the method. The &KEYARG will be translated into attributes with the same name and type as in main view. You have to add PL/SQL code according to PL/SQL guidelines between BEGIN
and END |
The development of user defined methods follows the standard in PL/SQL
development. It is very important to use all standard attributes ( see above)
and standard LU relations (see above).
Concentrate on high encapsulation of LU methods. This is done by using utility
classes and make large effort in finding correct LUs for the methods.
The following example shows how PL/SQL-code is added to the designed user-defined method Cancel for the LU Order. The interface will be generated in the API-file and the implementation stub will reside within the APY-file.
PROCEDURE Cancel ( order_no_ IN NUMBER ) IS BEGIN NULL; END Cancel;
The system service Reference_SYS is used at standard remove of LU objects. The system service checks all restrictions due to the object model.
How the restricted checks will perform is defined when the reference options for the attributes are defined. See Modify LU attributes.
This implicit functionality is matched between the server templates for logical units and the system services within Reference_SYS. The methods used are Check_Restricted_Delete and Do_Cascade_Delete.
PROCEDURE Check_Restricted_Delete FOR each view referencing current LU IF (option = 'RESTRICTED') -- Count references in view with key values set Restricted_SQL_Ref___(view, col_list, key_list) ELSIF (option = 'CUSTOM' or option = 'CUSTOMLIST') -- Just run the specified PL/SQL procedure checkPL Any_PLSQL_Ref___(checkPL, key_list, ref.option_name) ELSIF (option = 'CASCADE') -- Find all childs, get OBJID and run Remove__(CHECK) Run_Cascade_Candidates___(view, col_list, key_list, CHECK) END IF PROCEDURE Do_Cascade_Delete FOR each view referencing current LU IF (option = 'CUSTOM' or option = 'CUSTOMLIST') -- Just run the specified PL/SQL procedure doPL Any_PLSQL_Ref___(doPL, key_list, ref.option_name) ELSIF (option = 'CASCADE') -- Find all childs, get OBJID and run Remove__(DO) Run_Cascade_Candidates___(view, col_list, key_list, DO) END IF PROCEDURE Set_Reference_Trace This method can be activated from the Console within IFS/Client or from a SQL*Plus session by using method in Reference_SYS. Note that this trace is dependent of DBMS_OUTPUT in Oracle Server so this option must be activated during the session. SQL> set serveroutput on SQL> execute Reference_SYS.Set_Reference_Trace(1); SQL> declare PL/SQL-block to execute X_API.Remove__
Let us assume that we have an association by reference between the logical units DemoOrder and DemoCustomer. We also have an aggregated association between Company and the two other. In this case the view comments on the view DEMO_ORDER will include a REF-tag to the LU DemoCustomer.
REF=DemoCustomer(COMPANY_ID)/RESTRICTED (default)
If an attempt is made to remove an instance of DemoCustomer, a check will be made in the view DEMO_ORDER to look for the value to be removed. If a customer exists in the view, an error message will occur describing the situation that the customer cannot be removed while connected to an order.
REF=DemoCustomer/NOCHECK
No checks at all except the code within Check_Delete___ will be performed and the instance will probably be removed from database without checking of any order references.
REF=DemoCustomer/CUSTOMLIST=(Check_Status_Reference,)
No implicit checking of view will be made, but a call to run specific methods for checking will be performed. Cascade methods may also be defined, but is omitted in this example.
COMMENT ON COLUMN &VIEW..customer_id IS 'FLAGS=AMIUL^DATATYPE=NUMER(6)^PROMPT=Customer ID^ REF=DemoCustomer(company_id)/CUSTOMLIST=(Check_Status,)^'
Demo_Customer_API:
----------------------------------------------------------- --------- IMPLEMENTATION BASE METHODS FOR DELETE ---------- ----------------------------------------------------------- -- Check_Delete___ -- Checks whether a specific LU-record may be removed -- or not. The procedure should check business rules -- like attribute values as well as database constraints -- (defined or not). -- -- Delete___ -- Deletion of the specific LU-object from the database. ----------------------------------------------------------- PROCEDURE Check_Delete___ ( remrec_ IN &VIEW%ROWTYPE ) IS key_ VARCHAR2(2000); BEGIN -- <<<Put your code here>>> key_ := remrec_.company_id||'^'||remrec_.customer_id||'^'; Reference_SYS.Check_Restricted_Delete(lu_name_, key_); END Check_Delete___; PROCEDURE Delete___ ( objid_ IN VARCHAR2, remrec_ IN &VIEW%ROWTYPE ) IS key_ VARCHAR2(2000); BEGIN key_ := remrec_.company_id || '^' || remrec_.customer_id || '^'; Reference_SYS.Do_Cascade_Delete(lu_name_, key_); DELETE FROM demo_customer_tab WHERE &OBJID = objid_; END Delete___;
Demo_Order_API:
----------------------------------------------------------- -- Purpose: Custom method to implement restricted delete. ----------------------------------------------------------- PROCEDURE Check_Status ( company_id_ IN VARCHAR2, order_id_ IN NUMBER ) IS rec_ &VIEW%ROWTYPE; BEGIN rec_ := Get_Instance___(company_id_, order_id_); IF (rec_.objstate = 'Open') OR (rec_.objstate = 'Closed') THEN Error_SYS.Appl_General(lu_name_, 'NODEL: There are some '|| 'orders referencing this object '|| 'that have not been invoiced.'); END IF; END Check_Status;
Example of other situations:
define LU = CustomerInvoice COMMENT ON COLUMN &LU..CUSTOMER_NO IS 'FLAGS=PMI-L^DATATYPE=STRING(10)^REF=Customer/CASCADE^'; COMMENT ON COLUMN &LU..INVOICE_NO IS 'FLAGS=KMI-L^DATATYPE=STRING(11)^'; COMMENT ON COLUMN &LU..AMOUNT IS 'FLAGS=AMI--^DATATYPE=NUMBER(15,2)^'; COMMENT ON COLUMN &LU..TYPE IS 'FLAGS=AMI--^DATATYPE=STRING(20)^REF=InvoiceType^'; COMMENT ON COLUMN &LU..STATUS IS 'FLAGS=AMI-L^DATATYPE=STRING(20)^REF=InvStatus/NOCHECK^'; COMMENT ON COLUMN &LU..COMMENTS IS 'FLAGS=A-IU-^DATATYPE=STRING(35)^';