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: Dictionary processes (webcon.com).
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:
The dictionary process will be better:
Examples
Example dictionaries created as a standard processes
1. 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.
2. 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
1. 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
2. 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.
3. 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.
