5 Create new function in ODT

This topic provides systematic instructions to create a new function in ODT.

  1. Log in to the Oracle FLEXCUBE ODT using the credentials maintained.
    Refer to Development Workbench – Administration document for creating the user.
  2. Map the session to the release and environment as required.
    Refer to Development Workbench – Getting Started for detailed explanation.
    Development Workbench Universal Banking- Home screen displays.

    Figure 5-1 Development Workbench Universal Banking- Home



  3. Click on the Function Generation node in the Browser tree.
    Function Generation screen displays.
  4. To create a new function in ODT, specify the details in the Header section:

    Table 5-1 Header section

    Field Description
    Action New and Load options are provided for this field. For a new screen development, select the action as New. If an existing screen Radxml has to be loaded for customization, select the Load option. If the action is Load then the corresponding Radxml has to be loaded using Browser option in Save Xml Path; all the header information will get populated.
    Function Id If the Action is selected as New, the function Id name needs to be specified. Function Id is the unique name with which a screen is identified. Function Id name should follow the FLEXCUBE standard naming convention.
    • Function Id name to have a maximum length of 8 characters.
    • For detail screens the third character should be D.
    • For report screens the third character should be R.
    • For call form function ids the third character should be C.
    • First 2 characters should specify the module name for which the particular function id is used(recommended).
    For Example: For Funds, Transfer Contract Input Screen name can be given as FTDTRONL. Here FT is the module (Funds Transfer), third letter D denotes it is a normal detail screen, and The length of the function Id is 8. If the action selected is Load, the function Id field will be disabled. It will be picked up from the Radxml which is loaded.
    Save XML Path The label description of the field will change depending on the action. If the action is Load, ODT attaches a Browse button to it so that the user can browse the Radxml and load it. If the action is New, save xml path is optional. If provided, then the generated units will be saved in the path mentioned. Note that the value in the Save Xml Path will be used only if the Save Format is Client Path and if the User has given CURRENT_DIRECTORY in the Work Directory under User Preferences.
    Function Type Function Type can be Parent or Child or Screen Child (based on the screen which has to be designed).
    • Parent: This is the default option and can be used for normal screen development.
    • Child: This option can be selected if the screen has to be the child of another screen; that is inherits all the properties of another screen which will be its parent. Properties can be modified at the child level.
    • Screen Child: This option can be selected if the screen has to be the screen child of another screen, that is it inherits all properties from its parent. Only screen layout changes can be done on the screen child screen.
    Refer respective documents for detailed explanation on Parent/Child/Screen Child screens.
    Parent Function This field is applicable only if the function type is child/screen child and this field will be populated when the parent Radxml is loaded. This is a read-only field.
    Parent XML This field is also applicable only if the Function type is child/screen child. If the Function Type is child/screen child user has to load the Radxml of the Parent Function using the browse button provided to this field. It is a non-editable field if the action is Load.
    Function Category Provide Function category depending on the type of screen being developed. ODT provides the following options:
    • Maintenance: These screens are typically used to maintain static data used across the system. These screens include product definition functions as well. For Example: Branch Parameters Maintenance
    • Transaction: These screens are typically used to capture contract-related data. Any operations related to contracts are performed on these screens. For Example: Funds Transfer Contract Input screen
    • Report: These screens are used to capture data required to generate BI Publisher canned reports. For Example: General Ledger balance report
    • Summary: If only query operation is required for the particular function Id, then the function category can be selected as Summary.
    • Others: If the developer feels that existing handles provided in maintenance/transaction screens in the extensible framework are inadequate (or not necessary) for the screen; the screen can be designed as others. Note that all business logic would have to be manually written by the developer for other screens.
    Header Template A template can be selected for the header. The following options are provided.
    • None: This is the default header and should be used for all screens except workflow screens.
    • Process: This template can be selected for workflow screens.
    The following Fields will be added to the header section as part of this template.
    1. Workflow Reference
    2. Priority
    Footer Template A template can be selected for the footer. The following options are provided.
    • None: This is the default value
    • Maintenance Audit: This template can be used for maintenance screens. Ensure that the master data source has the standard audit columns.

      Table 5-2 Maintenance Audit column

      COLUMN NAME BLOCK FIELD NAME
      MAKER_ID MAKER
      MAKER_DT_STAMP MAKERSTAMP
      CHECKER_ID CHECKER
      CHECKER_DT_STAMP CHECKERSTAMP
      MOD_NO MODNO
      RECORD_STAT RECSTAT
      ONCE_AUTH ONCEAUTH
      AUTH_STAT AUTHSTAT
      Audit block field names are reserved filed names and hence cannot be used as the name of any other block field.

      Note:

      when the template is selected, ODT automatically adds the fields to Data Source and Blocks, and adding these fields manually to data blocks results in erroneous behavior.
    • Maintenance Process: In this template along with maintenance audit fields system would automatically add a control block and Process related fields. This template can be used for workflow maintenance screens.
    • Process: Only process-related Fields will be added to the Footer. This can be used for workflow transaction screens. As part of the process template; previous remarks, remarks, outcomes, and audit block will be created in the footer.