8 minute read

Part introduction

This is part 5 of my “Building Business Processes with WEBCON BPS – an expert guide” in WEBCON BPS. In the previous part we have identified all workflows which store the selected user in a person field. This completed the retrieval of the workflows and it’s time to turns those object ids to text.

Tip: If you are a seasoned WEBCON BPS Designer you can scroll through this text and look out for boxes like this one. These contain tips / summaries and the like. You may find some useful information without reading everything.

Retrieving translations of WEBCON BPS elements

Distinction between translations types

There are two translations types. These are user interface content and object translations. The latter are used when an application, process or anything else is translated, which we are going to use. The first one is used for fixed elements in the user interface. For example, the save button in Designer Studio. You can find more information here: Translation of WEBCON BPS Portal user interface content

Internal working of object translation

As we already seen here WEBCON BPS objects can have translation. They have an internal name and for each language an additional one can be provided. Sometimes it’s necessary to retrieve the translation of an object at runtime. Ok it’s not necessary, but it’s more user friendly if you don’t display your internal name to the user especially if you have translations for it. In our case, we have the ids of the application, process, workflow and form type and want to display the translation of these elements to the user.

The translations are stored in the table Translates, but you won’t get very far with this table alone:

Data in table Translates
Data in table Translates

Every table has an _ID column which is the key of the table, but what are these other columns:

  • TRANS_LANID points to the table TranslateLanguages where we have a mapping of languages to an id

    Explanation of column TRANS_LANID
    Explanation of column TRANS_LANID
  • TRANS_OBJID is the id of the object which translation we want to retrieve. But since each id of each object starts with 1 there would be duplicates if there wouldn’t be some kind of distinction.
  • TRANS_ELEMID serves this purpose. It defines the type of the object. But how do we know which id represents our application name? This information can be retrieved from the table DicTranslationsObjects.
TRANS_ELEMID is mapped to TypeId in DicTranslationsObjects which holds explanations for the id
TRANS_ELEMID is mapped to TypeId in DicTranslationsObjects which holds explanations for the id

Tip: WEBCON BPS has evolved over more than ten years to become what it is today. So there have been a few naming changes in the UI which couldn’t be reflected in the core of the system. Two obvious ones are Process, which have been Definitions, and Form Types, which were Document Types at some point in time.

Tip: If you see an integer value and it looks like it should have a meaning, your first bet is to look at Dic* tables. Dic is the abbreviation for dictionary where you may find a mapping of the integer to a meaningful name.

Getting translations via Business Rules

So, we have the translation but how do we make use of them. We need a data row to our item list. With this we will retrieve the translation for our object. We could write our query there, but this would be a waste. Getting translations this seems like something which can be reused, and this is where Business Rules come in. They allow us to create a rule which we can use again and again. Business Rules can be defined on process level or global, which allows to use the rule everywhere. Overtime there will be a lot of rules. Using groups will help you getting a better overview of your rules.

Example of global business rules in groups
Example of global business rules in groups

Since a Business Rule is there to be reused, parameters can be provided. After looking into the dictionary table we know that the ids of Application name and Application description are 51 and 52. We can add these information in the description of a parameter.

Business Rule GetTranslationOfApplication has to parameters
Business Rule GetTranslationOfApplication has to parameters

Remark: You will see the description of the parameter only when you edit the rule and nowhere else.

The parameters can be used inside an expression like any other variable.

Parameter variables have another colour.
Parameter variables have another colour.

Even so these are fixed values I tend to create constants for those, which I will group, too.

Constant for ProcessName which has been called Definition in the past
Constant for ProcessName which has been called Definition in the past

I created query to create the constants by copy & paste:

SELECT 
[Name]
,'Translation of Column:'''+[ColumnName]+' in Table:'''+[TableName]+'''' as TranslatedObject
,[TypeID]
,[TableName]
,[ColumnName]
FROM [dbo].[DicTranslationsObjects]
Result of query to create translation constants
Result of query to create translation constants

These constants can be used in the expression editor as well as in the parameter mapping window, which is shown further below.

Usage of constants in business rule definition
Usage of constants in business rule definition

An example SQL statement for retrieving a translation of a application with a fall back if no translation has been provided.

select isnull(
  (
    select Trans_name 
    from Translates
    -- Trans-ObjId See table DicTranslationsObjects
    where TRANS_OBJID = OBJECT_TYPE_PARAMETER
    and TRANS_ELEMID =  ELEMENT_ID_PARAMETER
    and TRANS_LANID = (select LAN_ID from TranslateLanguages where LAN_Name = '{USERLAN}')
  ) 
  -- Fallback if no translation exists 
  , 
    (select 
        case OBJECT_TYPE_PARAMETER 
          when 51 then APP_Name
          when 52 then APP_Description
          else 'Unknown object id in GetTranslationOfApplication'
        end as DefaultValue
      from WFApplications
      where APP_ID = ELEMENT_ID_PARAMETER
  )
) as Translation

Tip: Grouping objects has one other benefit. If you right click on the group name, you can select one of the group members.

Right click on the _group name_ opens a context menu to select other group members
Right click on the group name opens a context menu to select other group members

Using Business rule in a data row column

All that’s left is to add a new column to the item list of type data row, write a simple SQL query select '' as Label and put the business rule inside the single quotes.

SQL statement to display the return value of a business rule
SQL statement to display the return value of a business rule

The parameter mapping of the Business Rule can be opened with a right click. What’s important to note here is the following, we need to fetch the correct translation for the current row. WEBCON BPS makes it easy for us. If we expand the workflows item list field, then we see all the defined fields and if we use one field, it will automatically refer to the value of this row at runtime.

Item list 'Workflows' is expanded to show it's columns
Item list ‘Workflows’ is expanded to show it’s columns

Remark: If we use information from an item list, we can’t test it in Designer Studio. The Designer Studio only loads data for a workflow and not for an item list row.

The result looks like this:

Translation of the objects are shown
Translation of the objects are shown

We no longer need our ids so we can hide them, but we shouldn’t do this via the field matrix. Instead, we make use of the Technical column attribute.

Even item list columns can be declared as technical
Even item list columns can be declared as technical

Technical columns allow us to hide unnecessary information for the normal user (1) and display it when necessary via the admin view (2) which is toggled via the admin button (3) in the menu bar.

Technical columns are displayed when switching from normal to admin view
Technical columns are displayed when switching from normal to admin view

Tip: Technical columns are hidden from the normal user, but only if they are marked as visible. If the column would have been hidden via the field matrix it wouldn’t have be available at all.

Tip: A group of fields, a field, item list and a column can be declared as technical. If you declare parent object like group or item list as technical, this will be applied to all child elements even so they don’t have the flag.

Retrieving supervisor

There’s not much to tell here. We need to update two fields of the item list. So we prepare the statement (1) and will add the retrieval of the wanted information in a second step (2).

Updating further fields in the item list
Updating further fields in the item list

Remark: You should always check for null, otherwise you will be surprised. Because select '1'+null+'2' will return null.

Concatenating a string with null will return a null value
Concatenating a string with null will return a null value

This action is executed on the transition to the next path.

The columns are populated and explain why a column was populated
The columns are populated and explain why a column was populated

Tip: If you populate columns with a complex logic, your users and yourself will be glad, if you provide some kind of information why a specific value has been set.

Remark

There’s room for improvement. We did not check the fields in item list and groups are ignored too. The latter shouldn’t be a problem since we can easily check the BPS Groups and the AD groups won’t contain the user anyway. The item lists should be checked but there’s nothing new to tell so I omitted it. It will be included in the downloadable application.

Continuation

At this step we achieved everything which was necessary for the parent workflow.

  • We need to fetch the workflows where a person is involved based on the above requirements.
  • We need to get the application of these workflows to get the supervisor.

What’s left is to inform the supervisors. For this we will create one sub workflow for each supervisor and copy over all workflows which needs to be checked. Afterwards we can come back to the parent workflow to create them.

Part overview

  1. Introduction and Use Case
  2. Parent Workflow- Prototype implementation using the Designer Desk
  3. Parent Workflow - Prototype changes and task retrieval
  4. Parent Workflow - Identify workflows by selected user
  5. Parent Workflow - Getting translations & supervisor
  6. Sub Workflow - User assignment task
  7. Parent Workflow - Starting sub workflows & monitoring column

Download

You can download the application from here.

Comments