Project Configuration
Last updated
Last updated
This is the place to change your project's name.
The Project Variables section allows you to define your own Setting fields. Then, within each Portal you can give this Setting its own Portal-related value.
The Value you give Setting fields for each portal, can be retrieved in the logic of your project using an expression with the function Setting("fieldname"), which at that point will yield the value for the active portal.
TIP: The project variables are text-only and usages can not be found easily.
With the introduction of Calculated Fields it is better to use that option for settings, because then you can use specifically typed fields (text, date-time, numeric etc) and with Find Usages see where they are used. Use the expression-function PortalId() to distinguish settings per portal and use a default value for all portals that are not specifically mentioned.
So in a way a Project Variable is a variable setting you can define yourself, to hold a value per portal within the project. Its type is always text, and its value is read-only within the logic of the project.
To remove a Project Variable (and all its Portal-level values), click to the left edge of the item to select it and make [x Delete] button becomes available. Then click on the [x Delete] button to remove the project variable.
Portals within a project can either share the data (in the Runtime) or have each their own separated storage.
If the various portals in a project all need their own data and/or prevent users from the other portals to access the data (like with a multi-tenant solution), you should choose to separate the databases (each portal its own storage). On the other hand, if the users of the various portals can or even must share the data, you share the database (this is the default setting when creating a new project).
NOTE: you can only specify the storage strategy (shared or separate), at the time when you create the project or shortly thereafter.
This setting cannot be changed once the project is previewed or published - because either of those actions will create the database container based on the chosen strategy - and, once the container has been created, it cannot be changed.
Here you can add and manage languages to be available in your project.
An overlay shows the languages already in your project and a button to add more.
Clicking [+ Add Language] shows another screen with a dropdown of available languages and a formatting example of the selected option.
If you hover over an already available language, an [x] button appears on the right. Click that [x] to remove the language from the list of available languages.
This part allows you to make changes to certain Project Features. This is introduced to support specific features available to WEM Kubernetes Runtimes (mostly Private Clouds), but which are not yet available on the standard shared clouds for EUR and APAC - also known as Legacy Features.
When you create navigation items, a path will be created using the name of the navigation item that will be added to the staging and live hostnames, so it can be used as a direct link to that specific navigation item. Navigation Items can be nested to a few levels, and the "old - legacy" way to generate URL Paths is "absolute", where only one path-level was created - a combination of hostname + navigation item name, without using the other levels. The new way, which is also standard for new projects, is to create relative paths, which creates several levels. Changing this setting for old projects (and then publish to Runtimes) may cause previously used links to stop working as their paths may have changed - so be careful when changing this setting.
Kubernetes Runtimes only!
From the beginning, Navigation Items added to the Menus in WEM are generated using HTTP POST requests to work properly with WEM User Sessions. The new Kubernetes-powered WEM Runtime can now also support GET requests for Navigation Items, from within the menus. But - this also requires to activate the new "automatic" Session Folder - as the GET requests need this specific Session Folder to keep connected to the user session.
Kubernetes Runtimes only!
This Session Folder Setting is only available when there is no WEM-Session folder created yet. Once this setting is activated, the Session Folder will be created and that action can not be undone (though you can choose not to put fields into that folder). This Project Feature will not be visible anymore when the Session Folder is created.
If your project already has a folder with the same name ("Session") - this folder will either be renamed to "Session Version" or you will be presented with a warning and asked to change its name.
The technical workings of this Session Folder is explained in more detail on the following page:
Query string parameters are name+value pairs added to the URL (https://en.wikipedia.org/wiki/URL) in the browser address bar (or to a link you click on) after the questionmark [?] indicating the end of the path and the start of the parameters. Check this wiki for information.
Let's look at this URL:
http://yourportal.live.wem.io/queryparam?uid=admin&action=resetpw
This URL contains two parameters: uid and action. The values are associated (passed) with the parameters you may want to use in your project.
Using the Project Configuration for Query String Parameters, you can define which parameters your project expects and to which fields in the Project's Data model the values are mapped. These can only be fields of type Text and may not be part of a list (because at the point of mapping from the request, there cannot be an active row on that list to put the values in).
Any parameter that is provided in the URL, but not defined as parameter in the WEM Project, will be ignored.
When the parameters are mapped to fields in the Data model, you can use these fields in your expressions and flows (and be smart to check if they have a value when you do - using the HasValue() function).
Query string Parameters can also be defined on specific Navigation Items (that have a URL-path defined and a deeplink with a flowchart linked) - of course via the context-menu on the navigation item.
The difference between the Parameters on Project level and the Navigation Item level, is that the Parameters on Project level can be used with every path within the Portal. The Parameters defined on a specific Navigation Item will only work when they are combined with the specific path of that navigation item, and then only in the Flowchart linked to this navigation item; not anywhere else.
WEM used to support an old version of Google Analytics. This was the basic version of Google Analytics (not the more advanced AdWords or other features). For information about GA, visit support.google.com. This setting is still available for old projects that have not yet migrated to newer versions.
This implementation for Google Analytics will no longer be supported by Google from July 2024!
A better approach - if you want to support the latest Google Analytics - is to use a Design Template that has the support for the current Google Analytics (or Tag Manager) embedded with a parameterized property for the Google Account ID.
The Design Template Customizable Main has this feature available (it is the only Design Template with this option), so if you use that Design Template, set the Google - Enable Tag Manager option to true (or based on hostname or other situations) and set the Google - Tag ID value accordingly.
If you want to use this feature in your own Custom Design Template, use the WMT tool to get a copy of the Customizable Main template to see the implementation and implement it into your own Custom Template. You will need the correct script to insert from Google, depending on your chosen service from Google Analytics. Use the example in the Customizable Main file mastertemplate.bwmt to see the proper way to make the parameters for the script itself and the Google Account ID.
An example:
When a list of Languages is made available in the Project level, you can set the language strategy (default language and how to select) on each portal. In the Multilanguage Dictionary tab, you can add specific labels and translations for each available language. When you remove a language, all translation items in the Dictionary for that language will also be removed.
WEM provides certain special features that perform combined, complex or specific actions by these Processes. In this overlay you can see the list of all available processes, a short description of their purpose, and a button to find their usages. These processes can be used on Flowcharts, using the Process Node. This will be explained in more detail later. The [Send Email] and [Generate PDF document] are probably the most used Processes.
