4 Screen Development

This topic describes about the development of screen.

Design and development of a Call Form function id is similar to any other function Ids. This section briefs the steps in designing a Call Form screen

For detailed explanation, refer the document: Oracle FLEXCUBE Enterprise Limits and Collateral Management ODT Screen Development

Header Information

Figure 4-1 Header Information


Description of Figure 4-1 follows
Description of "Figure 4-1 Header Information"

Note the following while providing header information

  1. Name of the Call form: Call Form name has to have the third character as ‘C’. This is how system differentiates a call form from other screens. Ideally, the length of the name should be 8 characters.

    Example: CFCTRCHG, ISCTRSTL etc are valid call form names

  2. Call Form Category: It has to be either Maintenance or Transaction depending on the functionality and the screens from which it will be invoked.
  3. Footer Template: Footer template can be provided as required. Note for Transaction screens, footer template has to be selected as NONE unless it is a process screen.
  4. Function Type: Parent and child functionality is supported for call forms.

Preferences

Note the following while providing Preferences for Call Forms.

Figure 4-2 Preferences


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

  1. Module name: Module name is a mandatory field and has to be provided. It is recommended that the first two letters of the function id is kept as same as the module name. Naming of the generated package will be derived from the module code maintained.
  2. Of the menu details inc generated, only script for SMTB_MENU and SMTB_FCC_FCJ_MAPPING is required for Call Forms
  3. Browser menu options: Call Forms cannot be launched independently .Hence browser menu labels need not be maintained. Script for smtb_function_description is not required for call forms

Data Sources

Identify the tables/views for the call form. Define data sources and add data source fields as required.

Figure 4-3 Data Sources


Description of Figure 4-3 follows
Description of "Figure 4-3 Data Sources"

Note the following while creating data sources

  1. Master Data Source has to be a single entry data source.
  2. Logical Relationships has to be maintained for all data sources except the parent.
  3. Provide PK Cols and PK types for all data sources.

If data source is a multi record block, then make sure it has at least one more pk than its parent which helps to uniquely identify each record of multi record block. Max length of the data source field can be modified as per requirement.

Figure 4-4 Data Sources


Description of Figure 4-4 follows
Description of "Figure 4-4 Data Sources"

Data Blocks

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

Figure 4-5 Data Blocks


Description of Figure 4-5 follows
Description of "Figure 4-5 Data Blocks"

Note the following while creating data blocks.

  1. Master Data Source has to be a single entry data source.
  2. Logical Relationships with the parent has to be maintained for all data sources.
  3. Provide PK Cols and PK types for all data sources.

    If data source is a multi record block, then make sure it has at least one more pk than its parent which helps to uniquely identify each record of multi record block.

  4. Provide Xsd node name if the block is normal and is required in gateway request

Figure 4-6 Data Blocks


Description of Figure 4-6 follows
Description of "Figure 4-6 Data Blocks"

Note the following while attaching block fields to data blocks

  1. In case the field is not required in XSD, check not Required XSD.
  2. Ensure that Related Block and Field are given for Amount Fields.
  3. Minimize the use of query data sources by using DESC fields wherever possible.

Note:

Query data sources is rarely required for a Call Form screen; as launch form can be used for query only screens.

Screens

Design the screen layout based on the requirement

Figure 4-7 Screens


Description of Figure 4-7 follows
Description of "Figure 4-7 Screens"

Note the following while creating screens

  1. One Screen should be identified as the main screen; if multiple screens present.
  2. In the function id ,where the call form is called is for the button (which launches call form) events, the main screen of the call form has to be mentioned.
  3. Screen Arguments :

    Screen Arguments has to be provided for the main screen. Any field which has to be populated based on the data from the calling Function id can be provided as the target block and target field.

    Normally values for the pk fields of the master data source can be retrieved from the screen arguments .Relationship between the calling function id and the call form will also be based on the pk columns of master data source.

Figure 4-8 Screens


Description of Figure 4-8 follows
Description of "Figure 4-8 Screens"

Note the following when creating tabs and sections for the screen

  1. If the screen does not have multiple tabs, then only the TAB_MAIN needs to be used.
  2. TAB_HEADER should not contain any sections in this scenario.

Field Sets

Not the following when attaching field to a field set

Figure 4-9 Field Sets


Description of Figure 4-9 follows
Description of "Figure 4-9 Field Sets"

  1. If a field value is passed as screen argument ,but is not required to be shown in the screen, The field has to be made invisible and attached to a field set.
  2. If it is not attached to any fields set, the screen html won’t contain the field and may result in script error while loading

Actions

Mention the web service and amendable information in Actions Screen

Note the following while maintaining web services and amendable information

  1. Call forms will generate only Type XSD. Operation specific message xsd’s will not be generated. Call form Type will be part of the main function Id xsd; hence separate message xsd is not required for call form ‘Subsys’ will be added to the name of call form type xsd.

    Example: for the example given in the figure, name of the xsd generated will be SubSysTxnChgDtls-Types.xsd

  2. Operation Id and Operation Code need not be maintained for the above mentioned reason
  3. Amendable information has to be maintained similar to any other function id’s.

Launch Forms

Launch Forms can be attached to a Call form screen. Though it is technically supported, practical scenarios where launch form is part of a call form is very rare. Process to attach launch forms is similar to any other function Id’s.

Call Forms

Call forms can themselves be attached to a call form. This scenario also is practically very rarely used. Processing logic (sub system pickup) for the attached cal forms has to be called from the main call form

Summary

Summary screens are not required for Call Form screens. Since a Call Form screen cannot be launched independently in FLEXCUBE, it doesn’t require a summary screen

Preview

Generate the units for call form and deploy them in the FLEXCUBE server for unit testing.