1. Development WorkBench Screen Development
  2. Data Sources- Guidelines and Best Practices

8 Data Sources- Guidelines and Best Practices

This topic provides a list of guidelines and best practices for creating data sources.

Below are the basic steps to be followed while creating data sources:
  1. Identify the tables and views involved in the Function being developed.
  2. Establish the hierarchy, Relation, and Relation Types among these Data Sources.
  3. Ensure that the correct and full relation is mentioned in the Relation.
  4. Identify the type of Data Source. It could be Normal, Summary, In Only, or Query Source.
  5. Ensure that there is only one master Data source for the Function.
  6. Based on the number of records that the data source might have for the function Id, set Multi Record to Y/N.
  7. System automatically defaults the PK Column information from STTB_PK_COLS while adding the data source. Based on the specific requirement of the function ID this can be modified.
  8. If the data source is mandatory, that is if it is a multi-record data source and has to have at least one record or if it’s a single record data source and is mandatory to have the record, check the mandatory flag.
  9. In case there is a need to have a default where clause or order by clause, mention the same in the respective fields.

Best Practices

Below are the practices to be followed while creating data sources:
  • Table/View/Synonym Names should adhere to the standard FLEXCUBE naming conventions. Tables or views should have the 5th character as _ (underscore). The name should not have underscores together (example: ACTB_TEST__ODT is wrong). Synonyms should have an S appended before the first underscore of their table/view name. For Example: Synonym for ACTB_DAILY_LOG should be ACTBS_DAILY_LOG
  • Avoid using views as much as possible. Don’t create a view data source with type as NORMAL. This will result in insert statements on the view in the packages generated.
  • Views can be used for query-only purposes, i.e. select the data source type as the query for views. These can be used for designing summary data sources or a query block.
  • PK Cols and PK types need not be the same as the primary key of the tables. It depends on the design logic.
  • If the data source is designed with relation type as 1:N with its parent, then it should have at least one more Pk col than its parent (assuming the relationship is based on pk cols). For Example: Assume STTM_CUSTOMER is the parent data source (1:1) with Pk col as CUSTOMER_NO; STTM_CUST_ACCOUNT is the child of STTM_CUSTOMER with 1: N relation with the parent. Here STTM_CUST_ACCOUNT should have at least 2 Pk Cols so that each record of the multi-record can be uniquely distinguished. CUSTOMER_NO and ACCOUNT_NO can be provided as Pk col so that each record can be identified with its account no. Relationship can be STTM_CUSTOMER.CUSTOMER_NO= STTM_CUST_ACCOUNT.CUSTOMER_NO
  • The parent data source has to be above all of its child data sources in the tree.