Implementation handbook – Application configuration compatible with DEV/TEST/PROD

Facebooktwitterpinterestlinkedinmail
Applies to version 2019.1.x; Authors: Kamil Nędza and Mariusz Burek

Introduction

DEV/TEST/PROD is based on separating the infrastructure into three environments:

  • Developer (DEV) – environment dedicated to developing business applications, testing configurations, and functionalities.
  • Testing (TEST) – environment dedicated to verifying the application by Business or IT departments. This environment allows testing if the application meets the user’s expectations, to verify the configuration of the process and if the migration was done correctly. With more complex processes, while migrating the application to the testing environment, you can prepare a complete plan of moving the application (e.g. moving views, tables, interfaces, websites, etc.) which then can be used while migrating to the production environment.
  • Production (PROD) – target environment on which end-users are working.

Illustration 1. Implementation changes scheme in DEV/TEST/PROD approach

 

Good practices

While creating new applications or modifying existing ones it is worth to abide by good practices. Adhering to the tips below seems to be a lot more time consuming, however, it helps to avoid many mistakes and will allow the whole team to work in a more orderly fashion.

  • Locking the environment – Designer Studio provides you with an option to lock the environment. This disables any chance to manually change any of the existing processes on an existing environment. Changes can be realized only by importing the application. Locking production environment is a good practice, but you may also consider locking testing environment as well.

Illustration 2. Environment configuration element which allows locking manual process editing

 

  • Using variables – each application configuration element has its own ID which is unique to the environment (processes, workflows, form fields, etc.). However, these ID’s are different between specific environments. Because of that while configuring processes use variables available in the context menu on the right. They allow mapping those variables to ID’s existing on target environment during application migration to it.
    Read more here:
    http://howto.webcon.com/export-import-good-process-design/
  • Using constants – within the process (process constant) or environment (global constant) you can define a constant which will return one specific value. This value can be different for each of the environments. Examples:
    • Global constant returning website address
    • Global constant returning ID of a specific SharePoint group
    • Global constant returning environment type, allowing, for example, blocking entries to the system from external DEV/TEST environments
    • Global constant with a text that will be added to the mail topic informing that the mail was sent from the testing environment
    • Process constant containing different quota thresholds for testing and production environments. Allows users to test functionalities unavailable for them on production environment
    • Process constant with user list split by semicolon allows, for example, to define tester group which additionally will be given a task on testing environments

Read more here:
http://howto.webcon.com/export-import-good-process-design/

  • Filling in DEV/TEST/PROD sections – in system elements which are different between environments (e.g. connections, data sources, constants) there are tabs to fill data for each type of environment. You can fill in the common value which is used when the value for the target environment was not defined. While creating an application a good practice is to fill all tabs immediately. Even if during implementation we do not know yet the value for a specific environment it is good to select “Brake inheritance” checkbox and leave it empty. This approach helps to avoid situations when an inappropriate value will be used – for example, an entry to the production system from the testing environment.
    Read more here:
    Connections and data source definitions – by Karol Woźniak

Illustration 3. An example of DEV/TEST/PROD tabs for connecting to MSSQL database

 

  • Different SharePoint website layout for each of the environments – helps to easily distinguish the environment on which we currently are. It is an easy change but allows to avoid registering workflow instances on production environment by mistake.
  • Using relative links – using relative links (both in the process, SharePoint website and on BPS Portal presentation layer) allows to export processes without worrying that on the target environment links will point to a different server.
  • Dedicated external resources for each environment – it is important that each environment has independent resources. Each environment should have independent HotFolders and HotMailBoxes so that environments do not rival each other and “steal” each other’s files. If the application communicates with external systems (e.g. ERP, HR, etc.) it is worth to take care about their testing equivalents or “mocks” which will simulate such a system.
  • Analogous website naming – along with process migration, information about connected websites and WEBCON Web Parts is moved as well. If websites on the target environment will have a different access paths (e.g. different website name or sub-site will be in a different location), then the configuration of WEBCON Web Parts will not be moved correctly.
  • Should behavior for DEV/TEST/PROD environments be analogous? – while creating an application you should be aware if the behavior on both environments will be similar. It is very important especially with processes with confidential data and where workflow sends data to external systems. For example, for workflows with information about users’ salary, it is important to prepare a dedicated testing data sources returning incorrect data. If we predict that we’ll be modifying user’s accounts data in AD on workflow level it is worth to know if this action should be done at all on the level of the testing environment.
  • GUID – security gate – all system configuration elements apart from ID have additionally GUID which unlike the ID is identical on all environments. Most of the functionalities can be done by using constants, variables and by filling in DEV/TEST/PROD tabs. However, there are scenarios in which mechanisms provided by WEBCON BPS are not enough. In those cases, you can use GUID, but remember that:
    • GUID is an unambiguous designation of a specific system configuration element (Process, Workflow, Form type, Form field, etc.). On each environment, GUID of a specific component is identical
    • On tables in BPS content database, an index is set up on the GUID column
    • Despite the index searching by GUID is slower than by ID

What the GUID is useful for:

  • Calculated columns on SWE Web Parts – while migrating the process we are sure that column will return correct data
  • RS reports – using GUID instead of ID, you can prepare a single report which will work for every environment. However, remember that this report will be less efficient compared to reports based on ID.

 

Process export/import

Process export moves most of the configuration. But which elements exactly?

  • Process/application or related processes/applications – during export the environment is verified by connections. Creator lets you choose which applications and processes should be exported
  • Connections – connections are always exported and imported. Filling all DEV/TEST/PROD tabs is critical
  • Business entities – all business entities are moved
  • Data sources – while importing there is an option to unmark overwriting already existing data sources
  • Languages and process translations – language definitions and translations are moved automatically
  • Global constants, Global form fields, Global rules – imported are those global configuration elements which are used in the process. In case they already are on the target environment, there is an option to unmark overwriting them during import
  • Web Part configuration – Web Part configuration is moved. Remember that website structure should be the same
  • MailApproval commands
  • BPS Portal reports and views – you can unmark specific elements of presentation layer both during application export and import
  • BPS Portal starters – you can unmark specific elements of the presentation layer both during export and import of the application
  • BPS Portal dashboards – you can unmark specific elements of the presentation layer both during export and import of the application

Process is moved. Is that all? No – some configuration elements need to be moved manually:

  • SharePoint Groups – SharePoint groups should be moved before application import. If groups used in the application are not in the target environment, the creator will not allow for application import
  • SharePoint websites – if SharePoint is used in the presentation layer or any website is used in an application, for example, to host files in SharePoint libraries, or there are dictionaries based on SharePoint lists, then they also have to be moved to the target environment. Remember that names and website locations are the same as on the source environment.
  • HotFolders and HotMailBoxes – create separate ones dedicated to the target environment and configure them additionally
  • Registration points – each environment has separately defined registration points
  • OCR AI projects – there is a dedicated mechanism to move OCR AI neural networks. Network exports itself on source environment and imports on the target environment. If the network was trained on source environment there is no need to train it again on the target environment
  • Service configuration – service configuration is defined for each environment. Process import doesn’t affect it
  • Views/Tables/SQL procedures – if the process uses additional SQL data structures which were created on source environment, remember to move them to the target environment
  • Word templates – from version 2017.1.3.33 you can use the same Word template for each of the DEV/TEST/PROD environments. This change eliminates the necessity of defining three independent Word templates dedicated to DEV/TEST/PROD environments. If Word templates were prepared in the old version, remember to also prepare Word templates for the target environment. In 2017.1.3.33 or higher versions there is no need to do that – if the template was created in this version, it can be used on all environments.

Leave a Reply

Your email address will not be published. Required fields are marked *