3 Screen Development

The design and development of an Online Form function id are similar to any other function Ids.

This topic describes the following sub-topics:

  • Function Generation
  • Preferences

For more information, refer to Development Workbench - Screen Development

Function Generation

On the Development Workbench Home Screen, click on Function Generation.

Figure 3-1 Function Generation


Description of Figure 3-1 follows
Description of "Figure 3-1 Function Generation"

The following fields are required to be provided for creating an Online Form.
  • Function ID
  • Function Category
  • Footer Template
  • Function Type

Note:

For more information on fields, refer to unresolvable-reference.html#GUID-DF0E10D9-B919-472E-98C6-C6BD3903A40B field description table.

Preferences

On the Function Generation screen menu, click on Preferences.

Figure 3-2 Preferences


Description of Figure 3-2 follows
Description of "Figure 3-2 Preferences"

The following information is required to setup the preferences for an Online Form.
  • Module
  • Module Description
  • Script for the following tables is generated by Workbench (menu details), which are essential for launching an Online screen.
    • SMTB_MENU
    • SMTB_FCC_FCJ_MAPPING
    • SMTB_FUNCTION_DESCRIPTION
    • SMTB_ROLE_DETAILS

    Note:

    The Online screens type string will be generated as Oin the SMTB_MENU table.
  • Transaction-specific action codes must be checked in the control string, whichever is applicable. For example, LIQUIDATE, ROLLOVER, REVERSAL etc.

Note:

For more information on fields, refer to Preference (xref) field description table.

DataSource

On the Function Generation screen menu, click on DataSource.

While creating the data sources, the following information is required.
  • Master Data Source has to be a single entry data source.
  • Logical Relationships has to be maintained for all data sources except the parent.
  • Provide PK Cols and PK types for all data sources. If the data source is a multi-record block, then make sure it has at least one more pk than its parent which helps to identify each record of multi-record block uniquely.
  • Minimize the use of views in the data sources. System-generated upload logic (fn_sys_upload_db) is not called within the system package for transaction screens. It is up to the developer to decide whether the system generated code can be used or not. If views are used in data sources, then this function should not be used by the developer.
  • Usually, a separate view can be used for the summary purpose for online forms. This view will have all the fields required to be displayed in summary. For example, LCVWS_FCJ_CONTRACT_SUMMARY

Note:

Max length of the data source field can be modified as per requirement.

DataBlocks

Determine the block structure for the function id. Define Data Blocks as per the design.

Figure 3-3 Block Properties


Description of Figure 3-3 follows
Description of "Figure 3-3 Block Properties"

While creating data blocks:

  • Master Data block has to be a single entry data source.
  • Provide XSD node name if the block is normal and is required in gateway request.
  • Block order and block field order can be changed by re-arranging blocks and block fields in the browser tree (drag and drop).

    Note:

    All units will have to be regenerated if block or block field order is changed (including xsd’s)
  • Related currency fields should be placed above the amount field in the tree.
While attaching block fields to data blocks note the following:
  • If the field is not required in XSD, check not Required XSD.
  • Ensure that Related Block and Field are given for Amount Fields.
  • Minimize the use of query data sources by using DESC fields wherever possible.

    Note:

    Query data sources is rarely required for an Online Form screen, as launch form can be used for query only screens.
  • The master block should contain reserved field names like TXNSTAT, AUTHSTAT, and SUBSYSSTAT(this is not shown). These are reserved field names that are essential for an online form. These will be used by Oracle FLEXCUBE Universal Banking Infra while processing. Normally TXNSTAT and AUTHSTAT are added as part of the footer of the screen.

    Table 3-1 Block Properties

    COLUMN NAME BLOCK FIELD NAME
    CONTRACT_STATUS TXNSTAT
    AUTH_STATUS AUTHSTAT
    SUBSYSTEM_STAT SUBSYSSTAT

Screens

Based on the requirement, design the screen.

Figure 3-4 Screen Details


Description of Figure 3-4 follows
Description of "Figure 3-4 Screen Details"

While creating the screens note the following.
  • One screen should be identified as the main screen.

Add Tabs, Sections and partitions as per the screen design.

When creating tabs and sections for the screen, note the following:
  • If the screen does not have multiple tabs, only the TAB_MAIN needs to be used. TAB_HEADER should not contain any sections in this scenario.
  • Normally Online forms are large screens with multiple tabs. In this case, all the tabs need to be used.TAB_HEADER should contain the header information. TAB_MAIN should be the first tab in the body. Other tabs have to be added in the body portion as required.
  • The developer often designs footers for Online forms. Provide sections in TAB_FOOTER as required.

    Note:

    In large screens, footer supports four partitions while other portions support three partitions.
  • If required, multiple screens can be designed.

FieldSets

Create Fieldsets and attach the fields to the field sets as required.

Figure 3-5 Fieldset Properties


Description of Figure 3-5 follows
Description of "Figure 3-5 Fieldset Properties"

When attaching field to a field set, note the following
  • If a field is not required in the screen but kept as hidden and value defaulted, the field must be made invisible and attached to a field set. If it is not attached to any fields set, the screen HTML won’t contain the field and may result in a script error while accessing the field.

Actions

Mention the web service and amendable information in Actions Screen.

While maintaining web services and amendable information, note the following.
  • Online forms will generate Type XSD and Message XSD. Operation-specific message xsd’s will be generated. For example, name of the xsd generated will be:
    • LC-Contract-Types.xsd (Type XSD for LC Contract)
    • LC-CreateContract-Req-Full-MSG.xsd (Create Message XSD for LC Contract)
    • LC-CreateContract-Req-IO-MSG.xsd (Create Message XSD for LC Contract)
    • LC-CreateContract-Res-Full-MSG.xsd (Create Message XSD for LC Contract)
    • LC-CreateContract-Res-PK-MSG.xsd (Create Message XSD for LC Contract)
  • Operation Id and Operation Code need to be maintained for the above reasons.
  • Amendable information has to be maintained similar to any other function ids.

Launch Forms

Launch Forms can be attached to Online form screen.

Figure 3-6 Launch Form Details


Description of Figure 3-6 follows
Description of "Figure 3-6 Launch Form Details"