Generate Database Objects

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 IFS/Design tool will, from the definitions in the model file, generate an Oracle view and packages (PL/SQL). Each LU in the model file will be converted into an Oracle view and a corresponding Oracle package. It is possible to add more views and packages to the LU once it's been generated, but the default is to have one view and one package.

The view is used in queries from the client. According to the query conditions the client will call the view in the database to receive the selected objects for the LU (see LU view structure ).
The package is used in all business logic called from the client. According to changes or checks the client will call the package methods. (See LU Package structure).

Two template files are used in conjunction with the Rose model to create the database objects. The template files include stubs for all standard operations. There are also a number of placeholders corresponding to different code fragments (e.g. Insert and Update statements). IFS/Design combines the templates with code generated from the model to create the actual views and packages representing the different LUs.

Contents

• LU attributes
• LU View structure
• LU Relations
• LU Package structure
• Code generation and template file contents

LU attributes

The LU includes all attributes defined in the Rational Rose model file. Some attributes are private and some are public. A public attribute will lead to a public Get method in the package specification of the LU. For the internal use the LU will also include the standard attributes Objid and Objversion. If there is a state machine for the corresponding class, the attributes Objstate, Objevents and State will be added to support this.

• OBJID: The internal identification for all LU objects. The objid is used for internal calls to Oracle packages. The objid is usually represented by the Rowid for the corresponding database table. The objid is defined in the APY-file of the LU. The actual representation of Objid is specified in the Model Properties section of IFS/Design, but can be overridden by setting the LU properties in the Business Logic section of IFS/Design.
• OBJVERSION:  The internal version of a specific LU object. The different versions of an object are used when comparing a LU object in the client with a LU object in the server. The objversion is usually represented by a time stamp or sequence column in the corresponding database table. The objversion is defined in the APY-file of the LU. The actual representation of Objversion is specified in the Model Properties section of IFS/Design, but can be overridden by setting the LU properties in the Business Logic section of IFS/Design.

Note: No matter how the objversion is represented in the database table it must be converted to a varchar2 in the view. The reason for this is that IFS/Client assumes that objversion will be a long string and won't work with anything else.

• OBJSTATE: The internal state of the LU object. The different states are defined by the LUs state diagram. The objstate is usually represented by a string column in the corresponding LU table. The objstate is defined in the APY-file of the LU.
• OBJEVENTS: The possible events for a LU object in the current state (OBJSTATE). The different events are defined by the LU's state diagram. IFS/Design will generate a function that returns all valid events for an object in a certain state (note that this function won't take conditions on events into consideration when creating the list).
• STATE: The client name of the corresponding state. The client name is translated to target language. The state is a translated value of the OBJSTATE value.

LU View structure

The LU view is created with all attributes in a logical unit - including objid, objversion and if necessary objstate, objevents and state.

Example

This is the definition of the view for the LU DemoOrder.

CREATE OR REPLACE VIEW DEMO_ORDER AS
SELECT
      company_id     company_id,
      order_id       order_id, 
      order_date     order_date,
      delivery_date  delivery_date,
      discount       discount,
      comments       comments,
      customer_id    customer_id,
      substrb(Demo_Delivery_Type_API.Decode(delivery_type),1,200) delivery_type,
      delivery_type  delivery_type_db,
      &OBJID         objid,
      &OBJVERSION    objversion,
      &OBJSTATE      objstate,
      &OBJEVENTS     objevents,
      &STATE         state
FROM demo_order_tab
WITH read only;

LU Relations

The table below describes the principles of how the connections in the design (associations between classes) are converted into Oracle PL/SQL code.

LU Package structure

The LU package is created to perform all operations on a single object of the LU. The package is separated in four sections of procedures and functions and methods will be sorted accordingly.

• Public: Methods that can be called from all other LUs.
  The name of a public procedure has no suffix.
• Protected: Methods that can be called in the scope of a LUs parent and all its children.
  The name of a protected procedure has a suffix consisting of one underscore.
• Private: Methods that can be called from the client part of a LU to the server part for the same LU.
  The name of a private procedure has a suffix consisting of two underscores.
• Implementation: Methods for internal calls and help functions in a LU.
  The name of an implementation procedure has a suffix consisting of three underscores.

See Template file contents for examples of procedures in the different sections.

Code generation and template file contents

There are several procedures and functions generated from IFS/Design. The code generating part is associated with the LU template files. Two sets of template files (one in older versions) are provided in Foundation1. Depending on the Foundation1 version those files are named:

IFS/Design generates different sets of methods depending on if the template is performance optimized or not. The code generated from the performance optimized templates minimizes execution time when running the application.

Major differences between optimized and not optimized templates are in the implementation section. Code generated from performance optimized templates works with tables instead of views, so the datatype &VIEW%ROWTYPE for LU record has been replaced with &TABLE%ROWTYPE. To see what methods are generated from Design see the following list:

Implementation, not performance optimized

The following implementation methods are generated if the LU has a state machine. Those methods should normally not be changed.

Implementation, performance optimized

The following implementation methods are generated if the LU has a state machine:

Private

The private methods Lock__, New__, Modify__ and Remove__ are interfaces to the client. Avoid using those methods when writing business logic. Changes should be put in the implementation methods instead.

The following private methods are generated if the LU has a state machine.

Protected

No protected methods will be generated.

Public

The following public methods are generated for IID's:

In addition to these, Get-methods will be generated for all public attributes in a LU. If the performance optimized template is used, a method called Get will be generated as well. This method returns the value of all the public attributes in the current LU. The return type of this function is Public_Rec which is a record defined in the package specification of the current LU. Here is an example how the public Get-method in the Customer LU can be used in the Order LU:

FUNCTION Verify_Order___( order_no_ IN NUMBER ) RETURN BOOLEAN
IS
     order_rec_ &TABLE%ROWTYPE;
     customer_rec_ Customer_API.Public_Rec; -- this will contain all
                                            -- the public attributes
                                            -- from LU Customer
BEGIN   
     order_rec_ := Get_Object_By_Id___(order_no_);   
     customer_rec_ := Customer_API.Get(order_rec_.customer_id);   
     RETURN (order_rec_.status = 'Ok' and customer_rec_.valid = TRUE           
             and customer_rec_.credit_limit > 0)
END Cancel;