Development guidelines

If you are rolling out an internal release through a staged rollout upgrade approach, it is recommended that you follow the predefined development guidelines to ensure that upgrade process is successful.

User Interface guidelines

Follow the stated user interface guidelines:
  • Ensure that you do not change the user interface column or the data mappings.
  • The new version user interface should be compatible with data from the previous version, for example, the following scenarios must be handled:
    • The order that is created from the older version pulled up in new version user interface.
    • The order that is created from the new version pulled up in the old version user interface.
  • Ensure that you use tagging to determine the version of the order and compatibility with the user interface.
  • The user interface design must always consider backward compatibility.
  • Ensure that the business codes is always be maintained.

Database guidelines

Follow the stated database guidelines:
  • Ensure that you do not add columns that require existing table reorganization.
  • Ensure that you do not add columns that impact the page size of an existing table. If the new added columns impacts the paging size, then ensure that you add an alternate table to handle such scenarios.
  • Ensure that you do not decrease the column size.
  • Ensure that you always add NOT NULL columns. That is ensure that you set all new columns to Nullable=true.
  • Ensure that you handle the default value in code. For example:
    <Attribute ColumnName="MATCH_MULTIPLE_REGIONS" DataType="Flag"
                        DefaultValue="'N' "
                        Description="This flag indicates whether to allow matching of multiple regions for a zipcode."
                        Name="Match_Multiple_Regions" Nullable="false" XMLName="MatchMultipleRegions"/>
  • Ensure that you do not change data type for an existing column.
  • Ensure that you do not change the existing view. During the staged upgrade, the views are not dropped as a part of the upgrade. Instead, a new view is created with the same view definition. For all the views that are changed, the view TableName must be changed to a new name and the view definition should also incorporate the new name. Thus, when the upgrade runs, if it is identified as a staged roll out version, the views are dropped but it is newly created. For example:
    Name="IBA_Ord_Demand_Vw" Prefix="YFS_" TableName="YFS_IBA_ORD_DEMAND_VW_95" TableType="TRANSACTION"
  • Ensure that you change the view name in the scripts that is used for creating the view. For example:
    CREATE VIEW YFS_IBA_ORD_DEMAND_VW _95(	IBA_ORD_DEMAND_VW_KEY, ITEM_ID,
  • Ensure that you create indexes or modify the indexes with a version. That is, indexes must be generated using the version as the identifier to the index name.
  • Ensure that follow the below guidelines for the unique indexes:
    • You can only add columns to the unique index.
    • The changing columns sequence should be a new index.
    • Add a version identifier to any unique index that is added.
    • Ensure that you always create an index first and then drop.
    • Ensure that you append the version identifier to the index name.
    • While altering the existing unique index, add validation attribute to the new columns that is added based on the version. For example:
       <Index DB2Name="PRCNG_RULE_ACTN_I1" Version="9.5"
       Name="YPM_PRICING_RULE_ACTION_I1" Unique="true"
      <Column Name="PRICING_RULE_KEY"/>
      <Column Name="ORDER_TOTAL"/>
      <Column Name="QUANTITY"/>
      Column Name="QUALIFIER_AMOUNT" Validate="9.5"/>
      </Index> 
  • Ensure that you follow the below guidelines for the non- unique indexes:
    • Add a new non unique index rather than altering an existing index.
    • Ensure that you only add columns to the non unique index.
    • Ensure that the changing columns sequence should be a new index.
    • Ensure that you Add version identifier to any non-unique index added.
    • Ensure that you always create an index first and then drop.
    • Ensure that you always append version identifier to the index name.
  • Ensure that you do not change a non unique index to a unique index.

Factory data guidelines

Follow the stated factory data guidelines:
  • Ensure that you do not delete or change the factory data.
  • Ensure that you do not change the resource or resource permissions.
  • Ensure that you do not provide primary keys for factory data.

APIs/Business Code guidelines

Follow the stated APIs/Business Code guidelines:
  • Ensure that you do not provide any data migrators.
  • Ensure that you provide a default template for an API, user exit, event and so on.
  • Ensure that you do not change the usage of a column value.
  • Ensure that you avoid specific handling of database object updates, inserts and so on. You can use the dbclasses for performing these operations or use updateRecursive(YFCDBContext ctx, <Entity> obj) for performing such operations.
  • For all the new columns that are added, always account for the Null value. Also, it is recommended that you use the existing logic without setting a default value.
  • Ensure that you do not introduce new columns for future use.

Customization guidelines

Follow the stated customization guidelines:
  • Ensure that you do not introduce new columns for future use.
  • Ensure that you do not change the default template for APIs, events or user exits.
  • Ensure that you do not change or remove the behavior of an input or the output supported attributes for an API.
  • Ensure that you do not mandate new attributes or require additional attributes for an API to work.
  • It is recommended that you avoid providing Business Code rules that enable or disable a particular product behavior.