2 Generate Files

This topic explains the systematic instructions to generate files from the development workbench.

  1. On the Function Generation screen, click on the Launch icon to generate the files.
    Generation of the screen has to be done after the design of the screen is completed. Refer Management ODT Screen Development for a detailed explanation of on-screen development.
    The Generate window displays. Development Workbench generates files as shown in the figure above. For action New, Workbench automatically selects all files. If function ID has been loaded, then hook packages will not be checked.

    Table 2-1 Front-End Files

    Field Description
    RADXML This file contains the Data Used to Design screen. Radxml is Input to Workbench. File Name : <Function_ID>_RAD.xml
    Screen Xml This file is an XML markup of presentation details, for the designed Function ID specific to a language. XSL Transformation is applied to this XML file by linking it to an XSL file. This results in HTML Markup which is displayed by the browser. File Name : <Function_ID>.xml
    System JS This JavaScript file mainly contains a list of declared variables used by FLEXCUBE Infra.
    • msgxml: This variable is used by the system to build FCUBS Request XML.
    • dataSrcLocationArray: This variable is an array of DATA BLOCKS.
    • relationArray: This array contains relation and relation type details of blocks. This is used for data binding.
    • retflds and bndFlds: These arrays contain LOV information.
    • CallFormArray, CallFormRelat, CallRelatType: These arrays contain call form details, call form relation, and relation type.
    • actionsAmmendArray: This array contains information for enabling fields based on actions.
    File Name : <Function_ID>_SYS.js
    Release Specific JS

    Note:

    Release Specific JavaScript File will not be generated by Workbench. This file, if required, has to be created by the developer.
    This JavaScript file allows the developer to add functional code and is specific to Release. The functions in this file are generally triggered by screen events. A developer working in KERNEL release would add functions based on two categories:
    • Functions triggered by screen loading events Eg: fnPreLoad_KERNEL(),fnPostLoad_KERNEL()
    • Functions triggered by screen action events Eg: fnPreNew_ KERNEL (),fnPostNew_ KERNEL ()
    A developer working in CLUSTER release would add functions based on two categories:
    • Functions triggered by screen loading events Eg: fnPreLoad_CLUSTER(),fnPostLoad_CLUSTER()
    • Functions triggered by screen action events Eg: fnPreNew_ CLUSTER (),fnPostNew_ CLUSTER ()
    In case if any function in KERNEL JavaScript file has to be modified, this can be achieved by overriding the function in CLUSTER JavaScript file. The functions in this file are generally triggered by screen events. A developer working in CUSTOM release would add functions based on two categories:
    • Functions triggered by screen loading events Eg: fnPreLoad_CUSTOM(),fnPostLoad_CUSTOM()
    • Functions triggered by screen action events Eg: fnPreNew_ CUSTOM (),fnPostNew_ CUSTOM ()
    In case if any function either in the KERNEL JavaScript file or CLUSTER JavaScript file has to be modified, this can be achieved by overriding the respective function in the CUSTOM JavaScript file. File name: <Function_ID>_<RELEASE_TYPE>.js

    Table 2-2 System Packages

    Field Description
    Main Package Specification The Main Package Spec Contains all the Declarations.
    Main Package Body The main Package would contain all the business logic and persistence code for the functioned. It will also contain call-to-hook packages. Different flavors of the main Package generated are:
    1. Maintenance FunctionId
    2. Transaction FunctionId
    3. Others Category FunctionId
    4. Report Parameter Screen
    5. Notification
    6. Purge Entity
    The main package has the below stages in case of a maintenance function:
    • Converting Ts to PL/SQL Composite Type
    • Checking for mandatory fields
    • Defaulting and validating the data
    • Writing into Database
    • Querying the Data from database
    • Converting the Modified Composite Type again to TS
    Each of these stages has Pre and Post hooks in the Release Specific Packages.

    Note:

    Main Package has the system-generated code and should not be modified by the developer.
    Upload Package Specification and Upload Package Body Upload Packages would support adapter upload flow of any Function ID. The package will contain code to convert upload table data to function id specific PL/SQL composite type. The main package of the functioned would be called to upload the data.
    Notification Triggers This will be generated only for notification trigger screens. Refer Development Workbench - Notifications for further reference.
    Kernel, Cluster, and Custom Packages are the packages where the respective team can add business logic in appropriate functions using the Pre and Post hooks available.

    Table 2-3 Hook Packages

    Field Description
    Kernel Package Spec and Kernel Package Body The Kernel package is solely for the Kernel Team to modify. The Main package has designated calls to the Kernel package for executing any functional checks or validations included in the Kernel Package. All the user level validations and conditional operations should be included in Fn_Post_Default_and_Validate. This function is called from the Main Package after the execution of Fn_Default_and_Validate. The user should avoid putting validations or code in any other function. In case the user needs to add a separate function, the existing Workbench generated structure should not be changed. Instead, the user can create a new package. For Example: <MODULE>PKS_<FID>_UTILS package. The desired function can be included in this package and the call can be made from the Kernel Package.
    Cluster Package Spec and Cluster Package Body The Cluster package is available to the Cluster Team to add any validations or Checks specific to the Cluster Team over and above the Kernel Team. The Kernel Team or the Custom Team should not modify the contents of this package.
    Custom Package Spec and Custom Package Body The Custom package is available to the Custom Team only to add any validations or Checks over and above those already present in the Kernel and Cluster Packages.
    Workbench generates INC files that contain insert scripts. These are static data required for the functioning of the function id. The developer needs to deploy generated INC’s in FLEXCUBE schema.

    Table 2-4 Meta Data

    Field Description
    Menu Details

    Under menu Details below 4, table entry Insert Scripts will get generated.

    • SMTB_MENU
    • SMTB_FUNCTION_DESCRIPTION
    • SMTB_ROLE_DETAIL
    • SMTB_FCC_FCJ_MAPPING

    If any one of the table entry missing while designing a new function ID, FLEXCUBE won’t allow launching function ID.

    Data source Details Generates INC for CSTB_FID_DATA_SOURCES. This data is required for uploading data to FLEXCUBE for the function id through excel.
    Lov Details Generates INC for CSTB_LOV_INFO. FLEXCUBE will be using this information to get data for the List of values provided on the screen.
    Block Details Generates INC for CSTB_FID_DATA_BLOCKS. This data is required for uploading data to FLEXCUBE for the function id through excel.
    Screen Details Generates INC for CSTB_FID_SCREENS.
    Amendable Details Generates INC for the below table. These scripts provide information regarding the amendable fields on the screen. Entry has to be present for the required field in these tables to make that field amendable through FLEXCUBE and gateway operation.
    • GWTM_AMEND_MASTER
    • GWTM_AMEND_NODES
    • GWTM_AMEND_FIELDS
    • GWTB_AMEND_NODES
    • GWTB_AMEND_FIELDS
    Call form Details Generates INC for CSTB_CALL_FORM_NODES. These will be generated only if the screen is a Call Form. It is required for attaching the particular Call form to any other function id.
    Summary Details Generates INC for CSTB_SUMMARY_INFO. Dat in this table is required for fetching records in the summary screen of the particular function id.
    Label Details

    Generates INC for CSTB_FIELD_LABELS and CSTB_OTHER_LABELS. Labels can be used for Language translation of screens. These scripts provide information regarding the label codes attached to each field. These are useful while developing language packs for Oracle FLEXCUBE Universal Banking.

    • CSTB_FIELD_LABELS : Contains Field Label details.
    • CSTB_OTHER_LABELS: Contains SCREEN, TAB, FIELDSET, BLOCK, etc label details.

    Note:

    that Workbench does not generate scripts for CSTB_LABELS. Data in CSTB_LABELS is maintenance required for the Tool.
    Block Pk Columns Generates INC for STTB_AUDIT_PK_COLS.
    Function Call Forms Generates INC for CSTB_FID_CALLFORMS. This data is required for uploading data to FLEXCUBE for the function id through excel.
    Gateway Details Generates INC for the below tables. Data in these tables are required for gateway operations (web services) for the particular screen.
    • GWTM_FCJ_FUNCTIONS
    • GWTM_OPERATIONS_MASTER
    Notification Details Generates INC for the below tables. Notification INCs will get generated only for Notification screens.
    • GWTM_NOTIFICATION_TRIGGERS
    • GWTM_NOTIFICATIONS_MASTER
    Function parameters Generates INC for the below tables. This INC gets generated only for Reports screens (i.e. Function Category – Report).
    • AETB_FUNC_MASTER
    • AETB_FUNC_DETAIL
    Purge Details

    Generates INC for the below tables. These scripts will be generated only for Purge Entity Definitions screens.

    • STTM_PURGE_MASTER
    • STTM_PURGE_TBL_DETAILS
    • STTM_PURGE_FILTERS

    Table 2-5 Others

    Field Description
    Xsds The XSD files are used for the creation of XMLs, which are in turn used during the execution of operations through Gateway.
    Screen html The HTML files are used to take screenshots by converting them to images, which are in turn used for Document preparation.
    Upload Table Trigger Trigger will be generated for inserting records into adapter upload process tables (CSTB_EXT_CONTRACT_STAT ,STTB_UPLOAD_MASTER) from upload tables.
    Upload Table definition DDL for upload tables would be generated. If existing upload tables are being re-used, the generated DDL’s can be ignored.
    Archive Table definition DDL for archival tables would be generated for Purge Entity Radxml. Synonyms for the tables would also be generated.

    Note:

    For the new screen, all file options will be checked automatically. For modification only system-generated files will be checked, based on user requirements can opt for other file generation.
  2. Click on Generate button to generate the files selected.