Standard or dictionary process – what process to use for storing dictionary data?

Facebooktwitterpinterestlinkedinmail
Applies to version: 2020.1.x and above; author: Dawid Golonka

 

Introduction

Some processes in WEBCON BPS require data from some other source to operate correctly. This data can be provided from external data sources such as SQL databases or SharePoint lists. Internal sources can also be created in the system such as Fixed value lists or references to data contained in WEBCON BPS workflows. Any WEBCON BPS process can be used as a source of data for another process, however, one of the newer WEBCON BPS features is the ability to create a dictionary process – whose sole purpose is storing information.

This article’s purpose is to help you decide what type of process to use for storing data and using it in other processes – a dedicated Dictionary process created from the wizard, or a normal fully customizable process.

The dictionary process

The functionality of the dictionary processes has been introduced in version 2020. Along with each dictionary process, a predefined data source is created, which returns all instances of the dictionary which are marked as ‘active’ via an unremovable checkbox form field.  The data source configuration contains all form fields defined in the process and is updated whenever the configuration of the dictionary process changes. This process is created by using the wizard and its workflows are always structured the same. One of the most important features is the ability to migrate the data in the workflow instances between environments.

For more information see: https://howto.webcon.com/dictionary-processes/ .

The standard processes

The standard process is created manually (without using a wizard) and requires manual configuration. The result is that the dictionary thus created is not standardized. In this type of process there is no option to import/export data between environments. But all other features available to regular processes are present.

Differences between processes

The table below presents the differences in individual features of both types of processes for supporting dictionary data:

Dictionary process Standard process
The process is automatically generated after selecting the appropriate option in WEBCON BPS Designer Studio The process is manually created
The data source is automatically created where data from the process form fields is stored The BPS data source (BPS internal view) must be manually created
The dictionary process consists of one workflow with one step – there is no option to add more steps and transition paths You may decide how many steps and workflows the process will have
The dictionary process does not support item lists, but the individual workflow instances can be launched and initialized using an Excel file added from the report level. Each data row from the Excel spreadsheet becomes a separate instance in the workflow In the standard process all form fields, including the item lists, can be used
The dictionary process can be easily and quickly (without additional configuration) completed and updated with large amounts of data from the Excel file. You can also manually add and modify instances The process can be manually completed via form or by configuring the Item list form field on the form which allows you to import data from an Excel file
Unable to add attachments Able to add attachments
The ability of data migration between environments There is no data import/export mechanism between environments, only process configuration itself.

 

Which solution should be used?

The application designer creating the supporting process should decide which solution will be more optimal for them. Before making a selection, you should compare the features offered by each variant against the requirements and expectations of your dictionary.

The dictionary processes will be better:

  • When you have the input data from a file (an Excel file, or text file that can be converted into an Excel spreadsheet). The data import/export mechanism from the spreadsheet is in-built function which does not require additional configuration in the dedicated dictionary process. Additionally, it is possible to migrate the dictionary process between environments – as opposed to the standard process.
  • When adding new data will be so frequent and there will be so many that entering them into the dictionary manually will be much slower than importing from an Excel file, and you do not need additional functionality that this type of process does not provide
  • When your process does not require any fancy action mechanisms or complex task assignment with multiple steps (e.g. sending e-mails, additional steps etc.)
  • When you do not need to save data in the dictionary in an item lists
  • When you do not need to add any attachments

The dictionary process will be better:

  • When for their operation the dictionary needs functionality not offered by a dedicated dictionary process e.g.:
  • Adding steps in which someone will approve data
  • Supporting different paths that will migrate data between steps
  • Data should be stored in several different statuses/states (e.g. active data, inactive, anonymized etc.) and this is handled by storing data in appropriate steps
  • The process will need to be integrated with other related processes (e.g. subworkflows).
  • On the data form, additional information such as data tables, statements (displaying e.g. invoice, vacation and contract data) will be displayed
  • Adding attachments will be necessary
  • When you have data stored in an Excel file and wish to import it to your process, but you need the functionalities of a regular process, you can import data into an Item list form field.

Examples

Example dictionaries created as a standard processes

  • Employee’s card – is used to store information about employees e.g. period of employment, type of contract etc. The employee’s card is often created as a standard process because as you expand the range of information that needs to be stored on the card, , new functionalities can be added to the card’s workflow e.g. approval of the employee’s card before entering it into the system, displaying lists of employees or adding attachments with contract documents and medical examination etc.

Below there is an example employee’s card which has been extended with additional functions:

Fig. 1. The employee’s card workflow

 

The first step is to submit a request for adding a new employee’s card – a person can accept or reject it. The active card can be deactivated and directed to the anonymization (delete all employee’s data) or reactivated.

  • Vendor’s card – the workflow may look similar to the Employee’s card workflow but when creating you should consider whether in the future there will be a need to add further functionalities such as adding additional steps, contract documents or tools using to the correspondence with the vendor.

Example dictionaries realized as a dictionary processes

  • Dictionary to store information about car fleet – the dictionary stores data such as brand, model, car description and their status (active/inactive. The set of data on individual cars is constant, and the need to add or deactivate the car takes place several times a year. The completed dictionary looks like this:

Fig. 2. The dictionary storing information about car fleet

 

  • The dictionary with the list of countries of the world – the dictionary stores names of all countries and information whether a given country belongs to EU. The designer of the process has all this data in the Excel file so adding them to the dictionary should not be a problem. Data in the Excel file which prepared according to the instruction of the “Dictionary process” article – the table template has been downloaded from the report by using the “Export to an Excel file” button:

Fig. 3. The Excel spreadsheet with a list of countries

 

Adding all 252 countries from the list by using the data import/export mechanism to the dictionary takes several seconds. The final result is presented on the screenshot below:

Fig. 4. Data entered to the dictionary

 

You can still manually change data via the form and import/export mechanism from the Excel file e.g. when a country joined to the EU.

  • The dictionary with a list of dishes – the dictionary can be used to store the menu available on a given day. To change the menu, upload the new version of the Excel file.

A list of dishes from the previous day looks like this:

Fig. 5. The dictionary content before updating a list of dishes

 

To update a list of dishes, you can download the Excel file and then, change the selected values:

Fig. 6. Change the dishes in the Excel file

 

Next, import this file to the dictionary:

Fig. 7. The dictionary content after updating a list of dishes

 

You can also update the selected dishes or prices manually e.g. in the case of importing data with an error.

Why is it important to update the previously downloaded Excel file (Fig. 6)? Because the data has already been added, and is represented by a workflow instance an therefore receives a unique identifier (GUID) based on which the system knows which rows should be updated and which are new rows and should be added as their own separate workflow insatnce. As an example, an Excel file will be added for the second time with the same dishes but with the incomplete ID column:

Fig. 8. The Excel file with incompleted ID column

 

In the report from the import operation, you will receive information about 9 new added elements – the dishes in the card has been duplicated and the system and assigned new GUID numbers:

Fig. 9. Information which you will receive after completing data import to the dictionary processes

 

Summary

Both methods of storing dictionary data have their advantages, being aware of the differences between them can help you make better informed decisions, or encourage you to switch from one method to the other.

Leave a Reply

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