EnterWorks - ETT 122 - How to Create Validation Rules for Different Environments with the Same Data Model

EnterWorks - ETT 122 - How to Create Validation Rules for Different Environments with the Same Data Model

Business Rules, Validation

rate limit

Code not recognized.

About this course

Most EnterWorks implementations have multiple environments, such as DEV, QA or TEST, and PROD.  These different environments each have their own external resources, such as import sources and export targets.  For example, Exports being sent to an S3 bucket may have a different bucket name for each environment, and exports being sent to an FTP server may have different directories within the same FTP server for each environment.
 
To ensure the wrong resource is not accessed in each environment, validation rules can be defined on the affected repository (such as Scheduled Exports) that only permits the environment-specific value.  However, if the validation rules are hard coded for each environment, the data model itself will become environment specific and must be altered after migrating from one environment to another.  These post-migration modifications would invalidate any testing conducted in the source environment and must be retested in the target environment after the modifications are made.
 
By defining the validation rules as Bulk Callouts and isolating the environment-specific information to the Configuration repository, it is possible to define a set of environment-specific validation rules that are identical in every environment, with the environment-specific settings being isolated in the Configuration repository.  This means the validation rules that are tested in the source environment are the same rules exercised in the target environment and do not have to be retested after being migrated.  This session shows how to use this approach to set up environment-specific validation rules.

Prerequisites - EBC 402

About this course

Most EnterWorks implementations have multiple environments, such as DEV, QA or TEST, and PROD.  These different environments each have their own external resources, such as import sources and export targets.  For example, Exports being sent to an S3 bucket may have a different bucket name for each environment, and exports being sent to an FTP server may have different directories within the same FTP server for each environment.
 
To ensure the wrong resource is not accessed in each environment, validation rules can be defined on the affected repository (such as Scheduled Exports) that only permits the environment-specific value.  However, if the validation rules are hard coded for each environment, the data model itself will become environment specific and must be altered after migrating from one environment to another.  These post-migration modifications would invalidate any testing conducted in the source environment and must be retested in the target environment after the modifications are made.
 
By defining the validation rules as Bulk Callouts and isolating the environment-specific information to the Configuration repository, it is possible to define a set of environment-specific validation rules that are identical in every environment, with the environment-specific settings being isolated in the Configuration repository.  This means the validation rules that are tested in the source environment are the same rules exercised in the target environment and do not have to be retested after being migrated.  This session shows how to use this approach to set up environment-specific validation rules.

Prerequisites - EBC 402