The WEM No-/Low-Code Platform, WEM in short (and Web Enterprise Modeler No-/Low-Code Platform in its longest form), is an all-round powerful rapid application building platform that can be used by any person without needing specific programming skills. A true no-coding development environment, which enables you to build enterprise-grade applications, for use in any browser (as a web application) or as a native app on mobile devices.

About the WEM Modeler

The WEM Modeler (or 'Modeler') has been designed to hide the complexity of software development and application deployment, enabling (business) users to visually create applications. At WEM, we call this 'Rapid Application Modeling'.

Before we dive into the WEM specific details, let’s look at what an application exactly is. According to Wikipedia: “An application program (application or app for short) is a computer program designed to perform a group of coordinated functions, tasks, or activities for the benefit of the user.”

To build and use an application, there are several components that make up an application, and WEM supports them all:

• All the user interface components, like buttons, forms, pictures, tables, input fields etc. These components exist in various application screens, or application pages and are the main interface for the user to work with. Within WEM we call these pages User Interactions manifested by Interaction Nodes in Flowcharts. The term Template is also used often, as it is often a template for a page where you can put placeholders that will be replaced with actual data when used by the end-users.

• All applications work with information, or data. Your application may need to store customer information, or enable users to add information to the system. In WEM, data can be stored using Database Lists. The WEM Datamodel provides many types of specific Fields (e.g. text, numbers, date/time values, files and others) that can be part of a database list. These fields can be stored in and retrieved from a permanent storage, or that can be used to keep values just for the duration of the user-session (i.e. the period while a user is actively using the application - ends automatically when browser is closed or when user has not been active for a certain period).

• Application logic: every application performs certain tasks and these tasks follow a certain application logic, or workflow. This is everything that happens ‘under the hood’, the engine that makes the thing work... To define how your application works, WEM uses Flowcharts: functional nodes connected by lines.

• Integration with external systems and applications is very important in modern applications. That can range from using Azure or Google to log into your application, to using complex data from ERP systems. Or even using public services to get information like ‘where is the nearest public restroom in Amsterdam’. WEM has been built with integration in mind, so there are various ways to easily and visually integrate your application with other systems. SOAP, REST/JSON, Import/Export (csv, Excel, Json, XML), SAML, OAuth, OData all have a place in WEM for easy integration in both directions (WEM as Consumer as well as Provider of integration features).

In conclusion, WEM has just about everything in place to help you build your own application, whether this is an online web-application or a native mobile app.

Modeling an application with WEM

With the WEM Modeler, building an application is quite easy: you visually "draw" the logic of your application in flowcharts using the available Nodes and Connecting Lines; organize your own specific data structure using folders, list and fields; and let WEM turn this into an application. This is what we call "Rapid Application Modeling". You can design your pages or forms, define all the data fields you need, integrate your logic with external systems/data, etc.

All the applications that are built with WEM are HTML5 compliant, so they work with all modern browsers. Furthermore, all applications are fully responsive, so they also work on your mobile device.

Learn how to use the WEM Modeler, and you will be able to build any application you need!

Deploying an application with WEM

When you have created your application, or at least some of it, you want to check how it works. For this, the WEM Platform offers the Preview: you can start your portal or a specific flowchart from the Modeler to see your work in action as it would as a fully deployed application. Debugging options are part of the preview, as well as (almost) directly showing changes you make in the Modeler.

While the Preview environment is only available to you as user of the WEM Modeler, you may want to make your application available to other people to test and provide feedback before "going live". For this purpose, WEM offers the Staging Runtime environment. You need a hostname (a web-address to point your browser to) and a valid License Key to start the Publish Process. This publish process takes care of your 'deployment' and pushes your project from the Modeler to the Staging Runtime Environment. This Runtime Environment is the part of the WEM Platform that provides access via internet to your application with all the appropriate security and availability measures in place. And the only thing you need to do to 'deploy' or update your application, is to push the Publish button in WEM Modeler! No worries about systems, configurations, servers, databases, networks, security. Just push that Publish button. The Staging runtime environment is the appropriate environment to pre-test or present your application to other users for acceptance before going live.

If you want to 'Go Live': another Push on the Publish button does the trick, this will push the version that is available on the Staging Runtime, to the Live Runtime. You can even have your own hostname/domain linked to it!

Surely there are many more details to describe the specific Runtimes and all related processes, but at this point, the take-away is: deploying your application in the WEM Platform is only 1 or 2 publish actions, started by click on a button in the Modeler...

The MyWEM Portal is the central location where you can access all your WEM information. You can access it via the Sign In link at the top of our Public WEM Website, or just follow this link and add it to your favorites!

Most important parts on MyWEM:

• Get Started (homepage): with links to useful resources, Free Online Training and Quick Start Projects, free to copy and study!

• My Projects: the list of your projects so from here you can start them directly in the Modeler.

• Forum: the WEM Forum where WEM Users and experts exchange information, answer questions and where updates and new features are first revealed! This now has been "promoted" to its own hostname at forum.wem.io.

• App Store: The WEM App Store contains WEM Projects that give you a head start on your application. Here you can also find WEM Widgets for download to be imported to your own projects. These projects and widgets are provided by WEM and its partners.

• Training: The dedicated Training Page, access to our Free Online Basic Training and the starting-projects for Exercises.

• My Support: If you need specific help in your projects, the Support Team is available via our own ticket system.

• My Details: Your personal page with account details, link to change Multi Factor Authentication options and even the option to be officially forgotten (GDPR compliant) via the edit-page.

A WEM user has a specific role within a Workspace or Project. When you create a new Workspace, you automatically become the Owner of that Workspace.

Via button [Manage projects & workspaces] in the Modeler, you can (with the proper rights) manage user roles.

Workspace Rights

Specific rights only applicable to a Workspace:

(Working upwards in the list as displayed above)

Rights applicable to all projects in a Workspace

User rights applied on Workspace level, will apply to all projects within the workspace, and will be applied to new projects created in this workspace in the future.

Any specific right is as described: there is no inheritance or implicitness. If you need to be able to publish to both staging and live, you need to have both specific rights. Publish to live does NOT give you the right to publish to staging implicitly.

Project Rights

For users that do not get Workspace-level rights, you can apply Project-only rights, applicable to only that project.

See the single "Project" label with some of the rights, as opposed to the plural "Projects" for the Workspace-level rights.

These Project-level rights can only be applied to users that do not have any Workspace-level rights. Any user either has rights on Workspace and therefore on all contained projects, or has rights on singular projects (and needs to get those specific project-rights assigned to every project).

----

The old role-based situation

Previous versions of Modeler used the following roles:

In schematic:

Workspaces, Projects and Portals

WEM uses Workspaces, Projects and Portals to organize applications on several levels:

• Workspace

  • Projects

    • Portals

Workspace

In a workspace you can group several projects that have things in common, like:

• Collection of Design Templates (styling definitions for look and feel);

• Runtime Environments (public shared cloud is standard, but private clouds can be made available);

• Custom SMTP settings for mail sending;

• Specific group of WEM Users that can work together in some or all projects contained in the Workspace.

Project

A Project can be of a specific type:

1. Web (with either one shared database or separate databases for each portal);

2. App (native mobile).

Portal

Finally, a Portal is the entity that can be considered the Application, the actual website or the native app that users will be using to access your created functionality and features. Portals have specific settings and configurations that define how users can access the application (hostname or app-file), how it will appear (Design Template and its custom settings), how it starts (home page), which language strategy and timezone strategy will be applied.

It is possible to create multiple portals in a project. You would do this for several reasons, for example:

• you want the same application to be available via different URLs, different look and feel, different starting points, different language or timezone strategies;

• the application is used by different organizations ('multi-tenant'), that access the application through their own URL and their have own look and feel;

These portals within a project can share the data (Runtime) or each can have 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, you should choose to separate the databases (each portal its own storage). On the other hand, if the users of the various portals can/must share all the data, you share the database (this is the default).

More details will be explained later on, but you will encounter these terms (Workspace / Project / Portal) often, so basic understanding of their meaning is useful.

Modeler Startpage

The access to your projects.

When you start the WEM Modeler, or go to the startpage by clicking on the button next to the WEM Modeler Title, you get an overview of your Projects, organized by Workspace, your recently accessed projects for quick access and some useful links.

• To open a project, just find the project you want to work on and click on it to open;

• The +New project button starts a wizard to create a new project and go through the basic settings;

• The Manage projects & Workspaces button gives an overview of workspaces you have access to, the projects therein, provides features to create workspaces, projects in a workspace, some settings and allow role-based access to other WEM users; Just click on the [...] to open a context-menu with the appropriate actions on the specific item.

Project Summary Page

When you have selected a project from My WEM or from the Modeler Start Page, the project opens in the WEM Modeler, and shows the Project Summary Page in the main container with information about the projects and its portals and last modified flowcharts and templates.

The WEM Modeler, or simply 'Modeler', is the "Build and Manage" environment that you use to create and model your application. This is your Online Development Environment to help bring your ideas to life (in the form of a web application that is...)

When you look at the Modeler, there are various sections that provide different functions, based on what you try to accomplish. Let’s look at the various components.

Modeler Menu Bar

At the very top, on the right you find a menu bar with several options:

Here you can:

• Go to Modeler Startpage

• Manage Project settings

• Preview your project from the starting point of a portal (Home Page)

• Publish your project to the Runtimes

• Open Documentation

• Access your account information

  • My Account

  • Manage workspaces and projects

  • Log out

Project Resources

On the left is the Project Resources Pane, where you will find your projects resources grouped in several tabs and organized in a hierarchical tree. This is where you can navigate through all parts of your project and create new items or change existing items.

Directly below the tabbar is a search box, in which you can search for elements within that tab by name (supported with autocompletion), technical name or element-id. Projects can start small and grow big over time. Therefor, finding elements is a very necessary feature - and there are many ways to locate elements (find usages via context menu, [ctrl+click] on links where an element is a property of another element, autocompletion in Expression Editor)

From left to right these tabs are:

These topics are explained in their respective pages further on.

Remember: on each element in the tree you can use the Context Menu using right-mouse-button or the [...] three-dot button. Using the context menu gives you access to actions such as:

• Create new item;

• Create new folder;

• Edit item;

• Rename item;

• Delete item;

• Find usages;

• And more depending on the specific type of item you are on.

Modeler Detail Tabs

The modeler tabs also have a context menu that you can open with a right mouse click on a tab. With this menu you can:

• Locate in tree/Open node in flowchart The locate in tree is a very useful function which lets you find the current tab in the resource pane tree, if you do this on a flowchart tab for example you will be taken to the flowchart tab in the resource pane with the current flowchart selected and highlighted. When you do this on an interaction node you will be taken to flowchart with the node selected and highlighted.

• Rename The rename option lets you rename the current tab and its element.

• Close This closes the current tab

• Close others This closes all tabs except the current tab and the Project Summary tab

• Close tab to right Closes all tabs on the right from the current tab excluding current tab.

How to build an application

Building an app with WEM Modeler is very straightforward:

1. Create a new project.

2. Complete all required settings.

3. Model your application using the WEM modeler. Specify the data your app needs to work with, the workflows that make the app work, integrate with external systems when needed and create the necessary user interactions.

4. Test your application using the Preview.

5. Publish the application to the Runtime so it is available for your targeted user-audience (Staging for acceptance testing and review, Live for the final real deal).

There is a lot more that can be explained about all these steps and detailed information can be found in the following pages and sections.

Projects are the basis of your application. Every application is created within a project. So to get started on a new application involves the creation of a new project. WEM provides a step-by-step wizard to create a new Project from scratch. On existing/copied projects you can change all those settings in the respective Project Settings and Portal Settings pages.

1. Project name and workspace

When you click on [+ New Project], you are presented with the following overlay, which is the start of a Wizard:

1. Enter your Project name;

2. Select type of project:

   1. Web application with shared database (1 storage for all portals in this project);

   2. Web application with separate databases (each portal its own storage);

   3. Native App project (Android and iOS apps).

3. Select an existing workspace or create a new workspace.

Click the [Next] button to go to the next step.

2. Localization

• Select your Default Language (this can be changed later per portal);

• Select your Time zone mode (this can be changed later per portal);

  • Option [From Client IP Address] will lookup the timezone based on the runtime user's IP-address using a lookuptable with known registered ip-address ranges and their known timezones. This may be affected by IP-addresses provided by international providers or free-wifi connectors, and it may be that some ip-addresses are not available in the WEM lookup table if they have been added recently; With this option you can use the UTC timezone (and related functions) to store specific date+time values, and choose to display them as local time to the enduser - based on their timezone.

  • Option [Fixed] will give you the option to select one specific timezone which will be used for any and all date-time values (like the technical time function Now()).

Click the [Next] button to go to the next step.

3. Domain names

Portals published to Runtime (staging/live) have to be made accessible using a hostname, the address you enter in the browser's address bar. WEM offers a few choices here:

• Hosting Zone: based on certain settings for your workspace, you may have multiple hosting zones available. Standard hosting zone is the Shared Cloud environment in the European zone. Other options may be the shared cloud in the APAC zone, or any private cloud which is made available to your workspace.

• Hostnames: the wizard automatically generates a hostname based on the European hosting zone and your project name, ending with staging.wem.io and live.wem.io. These domains already exist and are defined with a wildcard in DNS settings, which makes it easy to just use any (unique) name without having to change DNS settings.

• Any portal needs 1 hostname per runtime (staging/live), but can have more! It will just be a different name (address to enter in the browser address bar) for the same portal, but it can be useful. Click on [Add hostname] to add more hostnames.

• Adding a hostname using the fixed ".live.wem.io" or ".staging.wem.io" will be operational with SSL-certificate directly after publishing.

• Adding your own custom hostname will require additional changes in the DNS management of the custom domain - this is out of WEM scope.

Click the [Next] button to go to the next step.

4. Select a design

The final step in the Wizard, is to select the Design Template which will be used as the Layout for your Portal. The Design Template will arrange the position of your navigation menus, header and footer options and the standard fonts and colors. WEM provides a range of pre-defined Design Templates, and each of them has some (or many) additional settings to change to your needs.

The [Customizable Main] Design Template is the template with the most options you can modify yourself (within limits) and is becoming the most-used Template.

Click the [Create project] button, and your New Project will be created with the provided settings.

Create your account

You need a WEM account to start building your own apps. This WEM Account is used for the Modeler (building applications) and the MyWEM portal (support, training, forum and other useful stuff around the WEM Platform).

Creating a WEM account is straightforward. Simply go to the WEM website and click Start for free, or go directly to the WEM Create Account Page.

You are now presented with the page to create a new WEM account:

Fill in the form and hit the [Create account] button.

You will receive an email asking you to activate your account. The link in that email is valid for 2 days. Please check your Junk or Spam folders in case this mail ends up there.

It is required to use this specific link once, to activate the account. If the account is not activated using this link within 2 days, you may need to request assistance from WEM Support (support@wem.io)

Multi Factor Authentication

After activation, you are also asked to set up MFA (Multi Factor Authentication), just to make your account and the usage of Modeler features more secure.

WEM MFA offers 3 options:

• Email (can be a different email address from your WEM Account)

• SMS (mobile number)

• Google Authenticator (mobile app generating random numbers every minute)

We advise to activate at least 2 of the 3 options, so you get a choice when you login to use the MFA option that is available to you at that time. You know, we all forget our phones sometimes, or transfer to a new phone - and then you need another option besides the Authenticator app which will not work anymore.

Trust one week option

After setting up the MFA, next time when you login to MyWEM or Modeler, you need to use one of the activated authentication methods. At that time, you can check the option "Trust this computer (skip MFA for a week)" to bypass the MFA option for 1 week; next time you access MyWEM or WEM Modeler, you only need to provide your Username and Password.

This only stays as long as you do not specifically logout but just close your browser when you're done working in the Modeler or MyWEM Portal. As soon as you explicitly logout, all settings (stored in local cookies) are removed and next time you'll need to provide your Username, Password and one of the MFA options again.

Change MFA Settings

If you want to change your MFA settings at a later moment, you can access your "My details" in MyWEM and click on the [Change MFA information] link below your personal information. This will bring you to the WEM Login Portal where you can click the [Manage Multi Factor Authentication] button near the bottom, that leads you to your MFA options so you can change your settings.

Cannot access MFA?

For security reasons, it is not possible to reset (to blank) your MFA options yourself once they are set. So it is highly recommended to have at least 2 MFA options setup, or even all 3 options, in case you have no access to your personal device (for SMS or Authenticator).

If you have absolutely no access to any options and need the MFA to be reset, you can send an email to support@wem.io (in English preferably) with the reason for this request to have MFA-options reset, and specifically your WEM account information.

Once you have activated your account and setup MFA, your account is ready and you can get started on that first app.

From the Modeler Start Page, you can access your Projects in several ways:

1. From the list of Recent Projects that you've worked on

2. From the Workspace-ordered list showing all workspaces and projects that you have access to.

3. Search a project by name - this will filter the list of workspaces and show all projects matching the search value.

To create a new Project from scratch, click the button [+ New project] - this will start a wizard to guide you step by step.

Click on button [Manage projects & Workspaces] to access management features on your projects and workspaces - based on permissions you have.

The [...] action buttons to the right, lead to the item-specific actions. The structure you see here, is:

• User (you)

  • Workspace

    • Projects

User actions

Create new workspace

Click the [...] action button on the line of your user (the person-icon and your name). The Create Workspace option appears. You only have to provide a name and you will automatically be the Owner of this workspace with all permissions.

The Edit account option is there as well, with limited options (full name, receive notifications, change password).

Workspace actions

Click the [...] action button on a workspace line to see the Workspace Action menu (see picture).

Project actions

Click the [...] action button on a project line to see the Project Action menu (see picture).

Click the [Settings] button in the top menu to access all Project and Portal settings.

The WEM Modeler is the central point in the Platform, providing the No-/Low-Code environment to create and manage the applications.

The WEM Runtime is the other significant element in the Platform, where the applications built in the Modeler get published to become available to the end-users.

The WEM Expressions Reference is where you will find everything about WEM functions, keywords, operators and data types. It also provides information about WEMScript, the specific script-language to use in powerful custom widgets and custom script blocks.

Support staff does NOT have access to your project, so if it is necessary to investigate your project in the Modeler, you should provide access to Support. Here's how you do that:

Allow Support Access to your Project

Step 1: go to Manage Projects and Workspaces:

Step 2: find your project and access the Context Menu:

Step 3: Click [Grant support access] and confirm.

Support employees can now access your Project in the Modeler, until you disable the Support Access.

Disable Support Access

To disable the Support Access, go to the [i] tab and see the information about the Support Access being active (when and by who). Click the button [Disable support access] when it is no longer needed.

Per portal you can select which SMTP Server you want to use to send e-mail messages from.

The list of available SMTP Servers is managed on Workspace Level (or in DevOps portal for Kubernetes Runtimes).

• Go to Manage Projects & Workspaces.

• On the specific Workspace, access the context-menu [...] and select SMTP Settings.

• On the overlay for SMTP Servers, add or edit an entry.

• Parameters to set, are:

  • Host (smtp server hostname, like smtp.gmail.com or smtp.office365.com).

  • Port (587 is the standard for secure SMTP via TLS).

  • Username (the account that can connect to the server and has sufficient rights to send messages on behalf of the from-address you want to use in your project's emails).

  • Password for that username to access the SMTP server.

After one or more SMTP server profiles have been set up, you can pick one on the Portal Settings to be used specifically for sending out E-mail messages using the Email Process Node.

Office 365 Account Settings

If you are using an Office365 account, following info is very important:

• The account-username to be used in the WEM SMTP Profile must be an active account in Office365 - you may need to specifically login to Office365 with this account as Microsoft may require this for accounts to be activated and checked with additional information - also check Multi-Factor settings that may cause issues when an application acts as non-interactive-user. This account may be setup as a non-personal account (like smtpsender@yourdomain.com).

• The Office365 Account must have a valid office license with a mailbox (so you can also see the Sent Items there and useful info like non-delivery-reports).

• The Office365 Account has permissions or aliases to send on behalf of all the addresses used in the FROM parameter of the email nodes in your application (like noreply@yourdomain.com).

• The Office365 Account must be setup using MFA and an App Password must be created. This App Password must be used in the WEM SMTP Profile Settings. This is necessary to work around the required Multi Factor Authentication and to enable another application like your WEM Runtime Portal to login to Office365 bypassing the MFA.

Portal Summary

As mentioned in , a Project can have multiple Portals. But must have at least one, so when creating any project, a Default portal is automatically created for you.

In this Summary block, you can see the following information:

• Name and type of the Portal: "Default" and Website;

• Home page: the starting point of the portal, defined by a specific Navigation Point which is linked to a specific Flowchart; [click] to change to a different item, or [Ctrl+Click] to locate in tree;

• Design Template: the selected design template that defines how the portal will look; [click] to change the selected Template or to change the specific Template Configuration

• Default Language; [click] to change the Language Settings;

• Timezone setting; [click] to change;

• SMTP Mail Sending Server Setting; [click] to change; You will get a list of available SMTP Servers to use for sending mail - these SMTP Server Profiles need to be setup in Workspace or DevOps Portal.

• Staging information: date+time last published and the configured hostnames; [click] to change;

• Live information: date+time last published and the configured hostnames; [click] to change;

Basic Settings

Basic Portal Settings is where you can change the Name of the Portal to something more meaningful than Default.

The Home page is the Navigation item that points to the flowchart that has to be executed when a user first accesses the portal (by hostname). The Home-Navigation Item and the Home Flowchart are automatically created and set as starting point for any new created project. You do have to add at least some nodes to the Home flow (at creation it only gets a start-node).

Select and configure design

The Design Template is the definition for how your application will look. It defines the base setup for all your pages in the project, generating the necessary HTML that browsers need to present the results to the user. The Design Template defines certain standard "containers" - blocks where standard elements like the Menu's go, what the main container is where all your own Interaction Templates will be put, the standard styling for all elements, fonts and colors.

Any WEM Design Template may support and provide specific setting-properties which you can provide custom values for in the Design Template Settings overlay.

Change language settings

WEM supports multiple languages. On the Project level you can define which languages you want to be enabled. Thereafter, on each Portal you indicate which of those languages is the Default language. Just select one from the available languages, or click the gear-button next to it to add more. You will see an example of the formatting for numbers, dates and times that the selected language will use when presenting these types of fields.

Then, you select an option for the strategy: should the default language always be used, do you want to follow the user's browser-settings regarding the language, or do you want to let the user actively select the language? For the latter scenario, a dropdown with all available languages (as set on project level) will be displayed in the top-row of each page.

There are other options available to allow the user change a language, or you can even allow users select a language and store it into a preferences profile. You can manage (check and set) the selected language using the appropriate process-nodes.

Change time zone

There are three ways to determine the time zone for end-users:

Manage license

Working with the WEM Modeler is free of charge, you can create an account and start getting to learn WEM and all its features without costs (just your time). You can also start your project in Preview, to test how it will work out for end-users.

Manage hostnames

On the Hostname Configuration, you can see the option [Force https]. If you enable this option, the portal will force each request to run with https (secure, encrypted using SSL/TLS). We do suggest to use this option, but you do need to activate this setting yourself.

Portals can run under multiple hostnames: they are just different addresses pointing to the same application. This is useful when you want to develop and publish early using the wem.io hostnames, and only when you are ready and have a custom hostname properly set up, add that hostname and start using the new hostname. Another practical use for multiple hostnames, is to provide one application to several different user-groups and make small differentials based on the hostname that the user uses, with the WEM Environment Function Hostname().

In the Add Hostname dialog we added some useful links to information about DNS and related info.

Manage custom error handlers

Sometimes an applications runs into an unexpected situation. For several of these situations you want to specify what needs to happen. You can do this by specifying a particular flowchart to which the application should jump when one of these unexpected situations occur. That may be simply displaying a more user-friendly error message, but could also result in executing some workflow/application functionality.

There are 3 possible Error Handlers for which you can define your own specific flow:

• Page Not Found: This can happen when a user tries to access a path that does not exist (for example a miss-typed address in the browser), no navigation item with a backing flowchart can be started > then the standard Page Not Found error will be displayed. OR if the portal has not yet been published and someone tries to access the hostname. This event can be caught and by selecting your own flowchart you can provide your own page and message, or redirect the user to the starting page.

• Unauthorized: Some elements in WEM have the property [Visible When] / [Allow Access When], for example on navigation items and files. When an item that a user is trying to access, is not visible or available, the Unauthorized situation is triggered, and you can use this custom error handler to determine what should happen (for example, send a mail to administrator to let it be known that unauthorized access was triggered - or just show your own friendly message). This Unauthorized flow can also be used manually in your flows, when you do your own custom check on access.

Publish to get changes available

Whenever a value in these Project- or Portal-Settings has been changed, you need to publish the project, in order to get the changes available in the Staging and Live runtimes.

Get Started

Providing a collection of blocks to give you starting points for useful WEM stuff.

• Documentation - to read about WEM;

• Quick Starters - get your copy of a WEM-built project with some features already available to get a jumpstart or to study and expand upon;

• Upcoming Events - provided by WEM and Partners to share information and experiences within the WEM Partner Eco System;

• Training - free online basic training as well as hosted sessions by Training Partners (if available);

• Latest Forum Posts - quickly see if there is something new (and link to the );

• My Support - your latest support tickets (and link to the support feature);

• Community - a link to the LinkedIn Community;

• Showcase - several videos on WEM, hosted on Vimeo platform.

My Projects

An overview of your projects in the Modeler, grouped by Workspace. You can filter on Workspace or search for a particular project by name. Every projects also has a direct link to open that project in the Modeler. Also some Quick Starters are made available here.

Forum

The WEM Community Forum is the place to ask questions and find answers; share your ideas and discuss topics with other WEM users. It has been promoted to its own portal and hostname: find it at .

Please read the forum guidelines as provided in an overlay before posting.

• Search feature - available in top-right corner at (almost) all times (using a Lucene implementation if you'd like to know).

• Favorite Threads you can keep to easily and quickly find when you need to.

• Overview of Popular threads.

• Additional sorting options within thread: used to be chronological only, now you can choose between oldest first, latest first or by most votes;

• Action Button on each post for post-related actions like: Vote (up or down), Reply with quote, Direct message to poster.

• Interactive chat, powered by Crisp Chat - to chat directly with WEM HQ.

• Easy management of your personal Forum settings and subscribed categories and threads.

App Store

The WEM App Store contains WEM Projects which you can install as a copy into your workspace to start with and modify to your own needs, as well as Widgets that you can download and then import into your own Widget Library to use in Interaction Templates.

These projects and widgets are provided by WEM and Partners.

The Quick Starters are provided as example projects with some specific features worked out to study and expand upon. They also provide guidance and tips using Notes on flowcharts and Comments in templates.

Click on any of the provided Project Tiles to open a detailed overview of the project and some screenshots on what it will look like. Click on the [Install] button to choose the target workspace where you want your own copy of the project. It may take a short while for the project to be copied and then you may find it in the Modeler and start using it.

Training

All available training material can be found here.

The WEM Essentials Online training takes you through the basics of building an application in WEM. The training is designed for all skill levels, provides examples and is accompanied by some Starting Point projects for exercises. An experienced developer can do it in about a day, while it may take a few days for someone new to building applications - but you can do it in your own tempo at your own convenience. If at some point you stop this training and want to continue later, just come back via the MyWEM Training Page and it will take you right back to where you left the training. WEM Certification will be introduced soon. Being WEM certified will show that you are proficient at building applications with the Modeler, this will help you stand out from the crowd. WEM has Training Partners that provide Instructor Hosted Trainings. Sessions which are open to public attendance will be displayed here.

Businesses and (potential) partners who want to have a "private" training for only a limited group of their intended WEM users can get in touch with WEM through the contact page, related WEM Partner or WEM Account Manager.

WEM Essentials Classroom covers the same subjects as the Online Training, with more personal focus and interaction to go deeper into details. This training is provided by our Training Partners and can be followed online, onsite or at a training center.

The WEM Pro: Integration is a next-level training on integration features in WEM using webservices (SOAP/REST), OData, SAML and more. Basic knowledge and some experience in creating WEM projects is required.

WEM Pro: Widgets allows you to create Custom Widgets to enhance the User Experience. Javascript knowledge is required - this is the low code part.

My Support

All support issues and questions, as well as feature requests can be addressed through My Support. You can create new support tickets, get an overview of the tickets you have submitted or see the details of an existing ticket. Because we have much to share about My Support, it is available in its own page:

My Details

My Settings provides information about your WEM-account and - if applicable - your company. At the top of the screen you will find your personal information:

Click on [Edit account information] to:

• Change your personal information;

• Add/change your Profile Picture;

• Change the information which is displayed on the Forum when you submit posts (which can be viewed by other WEM users in the Forum);

• Remove your personal information (GDPR): the action [Forget me] will disable your account in MyWEM and the WEM Modeler, and it will replace all your personal information (email address, name, phone) with random characters. This way we make sure that your account is no longer identifiable as any personal information, while we still can uphold our required business administration.

In the next block, your company's information is displayed. If applicable - that is, your Company has some kind of business agreement with WEM - MyWEM can link co-workers together, make workspaces and projects available to co-workers within the same licensed company and include information on the license that is used by your company.

If you have the authority (proper role attached to your account in MyWEM) to manage the company's information, you can change the basic information and manage the contacts for the Company within the context of the WEM Platform. The role you need to access this information, is either 'Business', 'License', 'Technical' or 'Security'. This role can be assigned to you by any other person in the company that already has this role, or your WEM Partner (or WEM itself).

Demo

You can send us a request for a Personal Demo on WEM.

Please provide all necessary information in the form, and most importantly: let us know in the Demo Details if you have a specific case in mind and describe it a bit. That way we can prepare a specific demo addressing your case.

We will personally get in touch first to finalize any appointment.

Certificates

WEM allows you to manage several kinds of Security Certificates in your project. These are certificates you typically use to either authenticate your portal to an external service, or to define whose certificates you trust and allow to access your portal.

• Client Certificates: These are certificates you use to authenticate your portal to an external service. This certificate must be provided (uploaded or by using the self-signed option) including the private key, because that is the part that makes sure that the external party (who only gets the public part) can be sure that you are who you say you are.

• Server Certificates: These are certificates again including the private key, which are used on a server level to indicate that the server providing the Portal can be trusted. This is also typically used when you use a Client Certificate that is provided or signed by a different server or authentication provider that may not be a global trusted Certificate Authority - in that case, providing that specific certificate including the private key, makes sure that when you use the Client Certificate - the external party can trust that Certificate because the server certificate is also provided with private key - indicating that you are you you say you are.

• Trusted Clients: These are the certificates that contain only the public part of external clients, that you choose to trust, for example when they access your custom endpoints or webservices that you can make secured using Client Certificates. The external clients that you want to trust and give access, should provide the public parts of their certificates to you so you can add them to your Project. When these clients then access the endpoint of your portal that is secured with certificates, they need to use their certificate (wiprivate key) to sign the request.

• Trusted Servers: These Trusted Server certificates hold the public parts of certificates that may be part of the Certificate Chain of a Trusted Client Certificate - and they also need to be trusted if they are "custom" (not on global trust lists). These are typically certificates that are used as Certificate Authority or Intermediate. In the case when a Trusted Client Certificate uses Custom Certificates in its Chain, it can only be fully trusted if all certificates in the chain are added to the Trusted Servers.

IP restrictions

WEM offers a way to allow or deny access to your project based on the IP-address of the client trying to gain access. This is also known as Whitelisting (allow specific IP addresses) or Blacklisting (block specific IP addresses).

Each rule is checked in the order as displayed. If the order needs to be changed, select a row by clicking the left-most edge of the row and see it highlighted or indicated, then use the Move Up or Move Down buttons in the toolbar.

Each rule has the following properties:

• Action: either allow or deny;

• Name: the name you give the rule to identify it;

• Start IP address: the starting IP-address of a possible range;

• End IP address: the ending IP-address of a possible range;

  • if both Start and End IP are the same, that indicates that one specific IP address;

  • Ranges should have the same first segments and only differ in the last segment to make a correct range;

• Portal: you can define for which specific portal this rule must be checked, or apply it to all portals;

• Runtimes: you can define for which Runtime environments this rule must be checked: preview/staging/live, or apply it to all runtimes;

• Endpoint: you can define for which Endpoint this rule must be checked: OData service endpoints, Webservice endpoints, or WEM (normal portal usage via browser).

If you want to have rules applied properly, and only the rules that you have defined, you need to add a final rule to close:

• Use the Allow all remaining connections if you are using a Blacklist approach - all other rules before this one are Deny-rules.

• Use the Deny all remaining connections if you are using a Whitelist approach - all other rules before this one are Allow-rules;

When these rules are set up or changed, you need to Publish the project to the targeted Runtimes for the rules to come in effect. These rules will then be applied just before the portal is actually reached.

There is also another option to specifically check the IP-address of the user trying to access your portal. In case you want to do something even more finegrained: use the function IpAddress() in an expression. The value will be something like "123.12.12.125" in text form, so you can use any available text-based comparison function to decide what to do.

OData logins

You start by creating a username and password. NOTE: the password is encrypted and not retrievable, so make sure you store it somewhere safe!

Next, you specify on which portal the access should be granted (any specific portal, or all portals).

Finally you define to which resources this login has access and which actions are allowed:

The expression editor is what comes closest to actual code in WEM. The expression editor can be used to create conditionals, make decisions, calculate values, create the logic for different components or fields, and create filters.

This is a field that is used for an expression:

The expression editor will open in a new window in the modeler as you click on the field. The new editor window is shown below.

The expression editor has a few important components. In the top right you can control the size of the editor and make it full screen or close it without saving the changes. When you change or add content in the expression editor you have to close it with the green "Ok" button so it is saved. If you choose cancel, you remove the changes and go back to the original. When closing the editor the expression is checked on its validity. If the expression is not valid, a pop up appears asking if you want to save anyway.

With the validate button your expression is checked on its validity and whether the right data types are used. When an expression is valid a green bar appears on the bottom of the editor. When an expression is found invalid a red bar will appear with the reason and the location of the failure.

Show functions

The show functions toggle on the top right of the editor is where you find a library with every function, keyword and operator you can use in the editor. The functions are sorted in categories by use-case and have a dot as icon if its a value instead of a function.

When a function is selected, an explanation field appears on the bottom. Here you find the syntax of the expression with the datatype of the parameters and a short explanation of what the function does. When a function has different forms with different parameters, you can switch between versions with the arrows below the function syntax. This will give you the new syntax and a new explanation. The question mark on the right is a hyperlink to the documentation of this function, where you find a more complete explanation with examples.

You can directly use the functions from this list by double clicking them. This will place the function with syntax in the editor.

Comments

In the editor you can make comments or disable certain parts of your expressions with the use of the /* tag. When a text or function is a comment the editor completely ignores it. To start a comment you use front slash followed by a star /*, to end a comment you use the star first followed by the front slash */. When you want to comment out everything from a certain point you can use just the start of comment tag without closing it.

Recognizing content

Navigation

Basic configurations

The WEM modeler supports creating apps for both android and IOS. Making an app in WEM works just like an Web app, with a few different settings and different portals. When creating an app you first give your project a name and select the App as project type, after that you get the localization settings just like with a Web app.

Portal settings

The portal settings are the different for Apps. Instead of one default portal, you start with an Android and an IOS portal which each have their own settings. As with web application settings, the portal actions can be found in the top right corner of the portal settings canvas.

The first one portal action is "Basic settings" for both Android and IOS portals. This allows you to change the portal name and the homepage of the portal. Thereafter, you have the android app settings and the IOS app settings. Here you fill in the Application ID setting, the version setting and the Permissions the app requires.

Both portals have an app icon setting. For Android, a simple PNG picture of your preferred icon sufficient. However, for the IOS icon setting multiple files are required for different sizes of the icon. To add these icons click on the icon size you want to change and a pop up will let you select the file.

The app splash screen is the image that appears when you start up the app. This is a temporary loading screen and does not have any content. You can upload a PNG and choose the background color with hex color codes for both portals.

For now we have one master template per portal (for Android and IOS) with each their own design configuration. Just like web apps you can choose your own design, or a design from the WEM library and personalize it in the design configurations.

Security settings and certificates

Certificates for works a bit different with mobile apps.

You can only manage your certificates in the security settings not in the web service tab. Mobile apps only support consuming webservices so you will only find those under the webservice tab.

Project Configuration and security settings

Project variables work just like the web app and allows you to add variables per portal. When you add a variable, the first column represents the android portal and the second one the IOS portal.

The project configuration tab is also where you can configure the languages which your project supports. When you select the languages settings a pop up appears. There you can find the available languages and add more languages to your project.

The Storage strategy allows you to define the database strategy. That is, either all portals use the same database, or each portal has its own database. This setting cannot be changed after the project has been published.

Processes settings for the mobile app is similar to the web app processes settings, and allows you to find process nodes by searching on a process.

Different from the web app project configuration is the absence of Google Analytics, and Query string configuration in the mobile app project settings.

The end node signals the end of the flowchart. When the end node is reached, the application will return to the spot where the current flowchart was started. Usually this means an interaction node that contains a button that started the flowchart or it continues in the previous flowchart.

Most flowcharts will contain 1 end node but it is not required. A flowchart can end in an interaction node with no exits rendering an end node not necessary. A flowchart can also contain multiple end nodes. A flowchart that does not end in an interaction node or a End node will produce an error.

Properties

The properties pane of the end node contains only 1 field: the name of the node. The default name is ‘End’. Usually the default name is sufficient but it can be changed if needed. This is especially usefull if multiple end nodes in one flowchart are used.

Multiple end nodes

In the example below 2 End nodes are added to the flowchart. When this flowchart is triggered from an interaction node it doesn't matter which End node is reached. In both scenarios it will return to the interaction node. If this flowchart is used as a sub-flowchart in another flowchart it will have 2 possible exits. 1 called "Save" and 1 called "Cancel"

When the flowchart reaches the navigation node, the application will open the specified navigation point and continue from there.

There are no exits and there is only one property: the Name. The name is the specified Navigation Point and cannot be changed in the flowchart. To learn more about Navigation Points, read the specific article on Navigation.

Important to keep in mind for the security of your applications is that navigation nodes bypass a navigation items visible when property. A decision node with the same expression as the navigation point can be used to reinstate the pages access protection.

The user interaction node is used when there is an interaction with the user. These nodes translate into forms or pages where a wide range of user interaction components can be used (forms, lists, buttons, images, charts, etc.).

Properties

The properties are accessed by selecting the node. The properties of the selected node are shown in the properties pane on the right hand side of the screen.

The Edit template button at the bottom of the properties form works the same as double-clicking the node: it opens the user interaction template editor.

User Interaction Node Editor

The editor is where you create the form / interaction that is needed to communicate with users of the application. This editor is also referred to as the "template editor". This template editor has to many features to explain in this chapter. Therefore a seperate section in this documentation is dedicated to the template editor.

A sub-flowchart makes it possible to use a flowchart in a flowchart. When the sub-flowchart node in a flowchart is reached, the flowchart that is defined as sub-flowchart will start. Any flowchart can be used as a sub-flowchart. This allows you to create and use flowcharts as reusable functions that can be used in multiple other flowcharts.

When you drag and drop a flowchart node from the toolbar to the canvas, WEM shows a popup window that allowes you to select an existing flowchart to be added as a sub-flowchart. It is also possible to drag and drop a flowchart directly from the flowchart tab to the canvas.

Properties

A sub-flowchart node has no properties. The property panel on the right does provide some information on the name of the flowchart and which exits it contains.

Sub-flowcharts can have multiple exits. Every End node in a (sub-)flowchart is also an exit of that (sub-)flowchart.

Basic Settings

This is the place to change your project's name.

Project variables

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.

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.

Storage strategy

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).

Languages

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.

Processes

Project Features

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.

Absolute URL paths of navigation items

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.

Navigate with GET requests

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.

Session Folder

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

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.

Google Analytics: deprecated

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.

<? Placeholder "GoogleTagSupport" default false
<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=<% Placeholder "GoogleTagId" default "" %>"></script>
<script>
        window.dataLayer = window.dataLayer || [];
	function gtag(){dataLayer.push(arguments);}
	  gtag('js', new Date());
	  gtag('config', '<% Placeholder "GoogleTagId" default "" %>');
</script>
?>

The Flowcharts area of the WEM Modeler is where you model the way your application should work. Here you define the workflows, processes and all other functionality that make up your application. This also includes the use of user interaction screens (the screens or pages that are the application to its users).

The first flowcharts

When you look at the flowcharts of a new project, you will always find the default Home flowchart. This is the starting point for your project. When you create a new flowchart, you can choose between two types of flowcharts:

1. Regular flowchart: These are the flowcharts that can include user interaction (forms, pages, overlays, etc.). Most of the flowcharts are regular flowcharts.

2. Action flowchart: When a flowchart is needed that does not require any user interaction (e.g. a calculation, some background process that needs to run, etc.), you use an action flowchart. If your action flowchart contains sub-flowcharts there can not be any user interaction in one of the sub-flowcharts. In some situations, for example exposing webservice functionality, you can ONLY use action flowcharts. Action flowcharts can be distinguised from regular flowcharts by the lightning bolt in the icon.

Flowcharts can be organized in folders. When you have a small application with just a few flowcharts this is probably not necessary. But when you have an application that consists of hundreds (or even thousands) of flowcharts, it is important to have a structured list of folders to organize flowcharts. The way you want to organize flowcharts is up to you, there are no restrictions on the WEM Modeler side. Below is an example of flowcharts that have been organized in multiple folders.

Creating Flowcharts

When you select a flowchart or map you can see three dots appear. When you click the dots or right click a flowchart or folder the context menu appears.

When you open the context menu on a folder you will get the menu in the left picture. Here you can choose to make a new flowchart or a new folder to be placed in the selected folder.

On the right you see the menu when a flowchart is selected. From there you can open flowcharts, Open a preview of just one flowchart or copy a complete flowchart inside your project. It is not possible to copy flowcharts to other projects.

Both of them give you the option to rename your flowchart, delete it or find its usages. Renaming it will change the name in your whole project without breaking its functions.

The Find usages option is a useful tool to quickly see where a certain flowchart is used.

Flowchart Editor

When you open a flowchart, you see the canvas on which you will draw the actual workflow. It contains a toolbar (top), the Nodes-toolbar (left) and the Properties and Exits pane on the right (when a node is selected).

Working in the editor mainly consists of drag-and-drop actions with nodes and exits or arrows. Nodes can be selected from the Nodes-toolbar and dragged onto the editor pane. Nodes are connected with exits or arrows by either dragging arrows from one node to the other when you press and hold the ctrl-key, or from the edge of a node to the other without the ctrl-key. What these nodes and exits represent will be addressed later in this section.

Moving on the flowchart editor pane can be done in several ways. Zooming in and out can be done via the buttons in the toolbar at the top of the editor, or through scrolling with your mouse or track-pad. Zooming focus is determined by the location of the mouse on the editor pane. Furthermore, you can move the pane with drag-and-drop when you click and hold the space bar. This allows you to move around your flowchart without zooming.

How to use flowcharts

Flowcharts are the heart of your applications. With flowcharts you model the way your application works:

• Model your business process(es)

• Model the flow of your application

• Create the User Interaction (forms, pages, overlays)

• Integrate with external systems

• Etc.

Creating a flowchart is pretty straightforward: You select flowchart nodes from the toolbar on the left side of the canvas and drag them onto the canvas. WEM also allows you to add nodes by selecting various elements from the Project Resources pane on the left of the screen. By connecting the various nodes you create a certain flow: you basically tell the system what should happen in what order. Every node is used for a specific action, like showing a form or retrieving data from an external system. With a node exit, you tell the system what to do next. This way you can use the WEM Modeler to graphically model your application.

In the example above we are adding a new case type, as part of a case management system. The steps:

1. The flow always starts with the Start node;

2. The next step is to add a new row in the Case Type list, using the List action node, where the selected action is "Add row";

3. After creation of the new row, the user is presented with a form to enter the specific Case Type information. This is done using an Interaction node;

4. In the form the user has two options: save all the information or cancel the addition of a new Case Type. Both options are visible in the flowchart.

5. When the user wants to save the new Case Type, the Save database list changes node is executed, and when this node exits, the flowchart also exits by pointing to the End node;

6. When the user decides to cancel the addition of a new Case Type, theDiscard all database list changes node is executed. When this node exits, the flowchart also exits by pointing to the End node;

The example above is a very simple flowchart that shows how the different flowchart nodes can be combined to model a certain function. In this example the addition of a new Case Type.

Node Exits

An important concept in flowcharts are the ‘Exits’. An exit is one of the possible ways a node can exit and is depicted by the arrows on the flowchart that connect the nodes. For example, a ‘Save’ button on a form can be an exit of a User Interaction node; information is stored and the form is closed.

Nodes can have multiple exits, depending on what happens within that node. In the example above there are two exits for the ‘New Case Type’ Interaction Node: Save and Cancel, which both refer to buttons on the form. When no specific exits are defined, the ‘Default exit’ is available.

An exit not only specifies how you can exit a node, but is also used to create your workflow. Every exit can be connected to another node and thus creating a certain workflow. When you model your application, but forget to specify an exit for a certain node, the application will show an error message because it is not clear what should happen. The only exception is the ‘End’ node. When this node is entered, the flowchart has completed and the application returns to the spot where this flowchart started.

Ignore User Input

Flowchart Nodes

On the left-hand side of the flowchart editor canvas, you find all the available nodes that you can use to create the flowchart and functionality you need. Simple drag and drop nodes on the canvas, and draw lines between the nodes to create the flow that is needed. The following nodes are available:

All support issues and questions, as well as feature requests can be addressed through My Support. You can create new support tickets, get an overview of the tickets you have submitted or see the details of an existing ticket.

My Support is the main self-service environment for your specific issues in WEM. The Forum is a close second, although you will use the Forum for more generic questions and discussions with all WEM users, while you will use the Support for help with project-specific Modeling problems or occurring error messages.

Create new Support Ticket

To create a new ticket, hit the [Create a new ticket] button.

Select the Element for which you want to create a ticket. An element is a specific part of the WEM Platform and gives the Support Team the first clue to where the issue may be (can be used to assign it quickly to the designated specialists if applicable).

• Generic: a no matter what, anything fits, I don't know where else to put it choice;

• my.WEM.io: for issues related to MyWEM;

• Modeler: for issues with the Modeler itself;

• License Key: for questions about requiring, changing or extending a license key to publish >> please use the special [License Key Request] button;

• Workspace, Project or Portal: for issues with one of your specific project (or workspace or portal);

• URL: for issues regarding a specific url (web-address);

• SSL Certificate: for issues regarding SSL certificates to have your portal running in secure https; for new custom SSL certificates please use the special [Request SSL Certificate] button;

• Native Mobile, Android or iOS: for issues regarding native mobile apps development in WEM;

Next give a meaningful subject, short description or title for easy reference of the issue or question in the Subject field - this will be displayed in the list of tickets. Then select the ticket type. You can choose one of the following:

• Bug – wrong behavior

• Bug – error message

• Feature request

• Network issue

• Question

• Complaint

• Data Breach

Once all the information "about the issue" has been provided, you can write a more elaborate description of the issue:

You can attach files to a ticket with screenshots to help clarify the situation.

When you’re done, hit the [Submit] button and the ticket is created. You will receive an email confirming the new ticket and Support Staff will be notified.

The system automatically takes you back to the ticket overview, where you can open your tickets to check the status, or add information (only for tickets that are open and have not yet been assigned to a member of the Support staff).

The process of handling tickets, may go through several stages, which is depicted with the Status (in the list and the details). The most important stages are:

• New: you've just created the issue, support staff is notified;

• Assigned: support staff has assigned the issue to a specific staff member;

• Status Update: support staff has made changes, which can be read in the history of the ticket details;

• Needs more info: support staff needs more information from you, the requested information will be in the history section of the ticket details;

• Ready for Review: support staff provided information for you to review;

• Resolved: support staff deems issue to be resolved, which may also be by having explained a specific situation or provided information to help you take the appropriate actions to remedy the issue.

When the status of a ticket is set to Resolved, the ticket is hidden from the list of active tickets. You can then close the ticket if you agree to the provided resolution, workaround or information. If you still need help on the same issue, you may Decline the proposed solution and add additional information why you declined, so the ticket will re-appear in the list of active tickets.

The clear session node is used to delete the current session and all related states (temporary data, flowchart stack, view state, comet listeners, et cetera). When a session is cleared, it will redirect you to the home page where it will create a new empty session. You can also specify another navigation item to return to.

The clear session node is an important safety measure that should, for example, be used in a log-out flowchart. This will make the logout permanent and prevents someone from returning to a logged in session by using the browsers back button.

The loop node makes it possible to loop through all the rows in a list or a multi-select field. When a loop node is dragged onto the canvas, a popup appears where you can select the list or multi-select field over which we need to loop.

When the node is selected the following properties can be specified:

A loop node has two different exits:

• Next row

  When a new row has been reached, the node exits with the Next row exit. In the flowchart the user has to make sure to return to the loop node, in order to loop over the remaining rows.

• End of loop

  When all rows have been looped over, the node exits with the End of loop exit.

The list node is used to work with lists. When a list node is reached an action can be performed on the list defined by the list node.

When a list node is created, WEM presents a popup where the list for which the action should take place is selected:

The properties and exits of a list node depend on the type of action that should be performed. The property table below presents all options:

The assignment node is used to assign a value to an item, like a data field, or an input field of a webservice. When the flowchart reaches the assignment node, that value will be set.

Starting from June 27 2022, the Assignment Node can be used to make assignments to multiple fields. This allows you to make multiple assignment very fast and easy and your Flowchart less cramped with all the assignment nodes when you need to update all fields from a list (for example).

When the node is added to the flowchart, the following popup appears:

From this popup you select the (writable) fields for which a value needs to be assigned and click the ok button.

It is also possible to add an Assignment Node to the canvas by dragging one or more (writable) fields from the Data Model to the canvas and selection the "Assignment" option.

Properties

When the assignment node on the canvas is selected the properties pane becomes visible on the right side of the screen. Through the assignment node properties pane a value can be assigned. Assigning a field from the Data Model can be done by selecting the "Advanced" action and dragging the required field in the expression editor. There is also an easier way that works by dragging the field directly from the Project resources pane and dropping it on the Action dropdown. This will change the Action to Advanced and sets the Expression to the dropped Field (its technical name).

The properties pane consist of the following elements:

Multi-Assignment Overlay

When multiple fields are selected (or added later) to the Assignment node, each field gets its own Assignment Action in this overlay. The overlay is accessible via the button [Edit Assignments] in the property pane or by double-clicking on the Assignment Node (when it contains multiple assignments). The actions and operands are the same as per single assignment node, specific to each fields data type.

Order

The order in which these assignments are displayed is important! It reflects also the order in which the assignments are executed. So you can actually assign a value to a field which then can be used in the assignment expressions in next fields. Use the buttons Move up and Move down to change the order of assignments. The assignment node itself cannot validate the order - you need to make sure the order is correct.

Actions

The list of actions that can be selected in the dropdown depends on which type of field is assigned. Almost all actions are very easy to understand based on the action name. In the overview below only the most common and most used are mentioned or those that could use some explanation. Add assignment nodes for different field types to the canvas to see all the possibilities.

When dragging and dropping a field to the Operand column the Action of that row is changed to the Advanced... option even when there is no input field shown. Fields that are non writable will be showing a red box in the drop-zone.

Save database changes

When the save database changes node is reached, all changes to all database lists that have not yet been saved, are saved.

This node has only 1 property, the Name. The value is set by WEM and cannot be changed by the user. The value is Save all database list changes.

There is also only 1 exit: Changes saved exit.

Discard database changes

When the Discard database changes node is reached, all changes to all database lists that have not yet been saved, are discarded.

This node has only 1 property, the Name. The value is set by WEM and cannot be changed by the user. The value is Discard all database list changes

There is also only 1 exit: Changes discarded.

The decision node is a very powerfull node that can be used to model bussiness rules in your application. In the decision node a certain condition is specified by using the WEM expression builder. When a flowchart reaches the decision node, the condition is evaluated and based on the outcome (the exit) the flowchart will take a certain route.

Properties

The properties pane of the decision node has only 2 elements: The Expression and a list of the available exits. Therefore it is easy to overlook the versatility of the decision node.

In the expression field it is possible to create incredibly complex statements combining multiple different expressions (like If Then Else, Choose, AND, OR). Allowing the evaluation of complex business rules.

Exits

Decision nodes have several exits, based on what the decision node needs to evaluate. Most people will only use a decision node which evaluates to True or False. However WEM also allowes decision nodes that evaluates to all other Data types. If the Data Type that the decision node returns is Text, Concept or Number, a button appears that allows you to create multiple exits. This opens a lot of possibilities. Some examples are given further down this chapter.

In the table below the most common exits are listed. Not all exits are available for every Data Type.

Default exit

Users have a tendency to only choose the exits that apply in the scenarios they expect. For example in a decision node with a boolean Data type only the Yes and No exits are used. Therefore the default exit is often times overlooked. In reality there are often edge cases that cause an error because the none of the exits used is suitable. Therefore it is advisory to always use the Default exit.

In the example below a decision node is used to evaluate if the user role of the current user is equal to administrator. If Yes then the user should be guided to an administrator screen. If No then the user needs to be guided to the main screen. In this scenario using the Yes and No exit would probably work just fine. But maybe a situation can arise where the expression can't be evaluated. In that case the user would see an error. To prevent that it is better to use the "Default exit" exit instead of the "No" exit.

The process nodes are distributed into 3 categories. Some processes change the settings of your project, confirm changes or affect flowchart flows, there can be found in the change settings category.

Other processes change files or change how documents work or change the document types. These can be found in the changing files categories.

Generate files is reserved for processes that generates new files or components for your project. Here you can find processes that; generate images, sends emails and much more.

The different processes:

Change settings:

• Change language

• Change timezone

• Confirm session changes

• Sleep

• Redirect

• Web request**

Change files:

• Resize Image

• Flatten CSV document

• Extract text from document

• Rename file

Generate file:

• Create data matrix

• Generate Word document

• Generate PDF document

• Generate file from text

• Generate Image

• Generate HTML from rich text

• Create QR code

• Create ZIP archive

Coming soon or Deprecated:

• Send email*

• Print template*

• Write template to rich text field*

Introduction

With the async task nodes you can run tasks in a background process. Async Tasks can be started, stopped and monitored with specific nodes. This can be useful if you want to start long running tasks without having to wait for them to finish. Users can continue their processes and work while the Async Tasks work in the background.

Start Task node

Use this node to start a task created in the project as a background process. Every process has a unique job ID that can be stored in a text dossier item to be used later.

Properties

• (Optional) Store job instance ID: Text dossier item to store the ID.

• (Optional) Task arguments: A list of optional arguments that can be provided as input for the task. The parameters are declared in the input folder under the task.

Exits

• Task queued: The task has been queued to run anytime now.

• Task queue limit reached: The task has not been queued because the limit has been reached.

Stop task node

Use this node to stop a running task with a specific ID.

Properties

• (Required) Job instance ID: Stop running task with this ID.

Exits

• Default exit: Task has been successful stopped.

• Error: An error occurred whilst stopping the task.

Task status node

Use this node to retrieve the status of a running task on demand.

Properties

• (Required) Job instance ID: The running task instance ID to retrieve the status from.

• Store status: Text dossier item to store general status information.

• Store feedback: Text dossier item to store custom feedback from the running task. For more information see the Task feedback node.

• Store error: Text dossier item to store general error information.

Exits

• Task queued: Task has been queued to run later.

• Task running: Task is running.

• Task stopped: Task has been stopped.

• Task stopping: Task is in the process to be stopped.

• Task error: Task has an error.

• Task completed: Task is completed.

• Task not found: Task has not been found.

• Default exit: The exit when other exits are not handled.

Task feedback node

Store any information of this running task instance to be read from other WEM runtime sessions.

Properties

• Feedback expressions: The shared information to stored.

• Append feedback: Should the extra information be appended?

Task input folder

Is a dossier folder of parameters for the current task. The arguments are given by the Start task node. Note that no lists or calculated fields can be created as input parameter.

The data import node is used to import data into a specified list. The data that is imported is either in CSV, Excel, JSON or XML format. To use this node, simply drag it onto you flowchart and choose the right file format, JSON, XML or CSV/ Excel. Next thing you have to do is change.

This node has two exits:

• Error- this exit is used when the import produces an error;

• Default exit - this exit is used when the data import does not produce any errors.

Edit Mappings

The Edit Mappings screen is used to map fields from a source (like a CSV, Excel, Json or XML file) to fields that exist in WEM. Depending on the file format the mapping tool works differently.

Map CSV or Excel fields

The easiest way to create the mapping, is to hit the Create mapping from example button on the right hand side of the toolbar.

You can now select the CSV or Excel file you want to import, so WEM can learn which columns exist. Once the file is selected, WEM will show a list of all columns from the source file. You can now specify per column to which target field in WEM the data should be mapped / imported. Simply double click on the target field column for the specific CSV/Excel column and WEM will bring up the popup so you can select the actual target field. If needed you can also specify whether this should be a mandatory field and what do do when WEM encounters an invalid value in the source file.

Map Json or XML

To map Json or XML to WEM data, hit the Create mapping from example button on the right hand side of the toolbar to open the mapping tool. When you do this the first time you will get an emtpy screen: no mapping is available. You can create your own mapping by adding your own entities and map these to WEM fields. But it is far easier to use some sample Json or XML and let the WEM modeler do a lot of the work for you. Click on the Create mapping from example button in the toolbar en paste your sample Json on XML into this form. You can verify if you are using correct XML or Json and then click on Ok to let the system create the basic mapping.

When you use Json, you get something that looks like this:

For every array, object, text field, numeric field and boolean you can now specify:

• Is this a mandatory component;

• Do you want to skip an object if the data is invalid.

You can specify this by simply clicking on the component in the tree on the left hand side. You will then see the properties on the right hand side (see ths picture above). Te map a component to a WEM field, simply select the Json field, and in the properties area on the right click on the button of the Map to field. You will get a popup where you can select the WEM field to which you want the map the Json component.

Once you have done this for the entire Json message, you are done with the mapping: click on Save and your mapping is ready to use.

If you want to import XML, you get something that looks like the screen below, after you have created the mapping from an example:

The actual mapping works very similar to the Json mapping described above. The main difference is that the various XML elements can have different properties, based on the value of other properties of the same element. But in essence it works like Json mapping: you can create the entire mapping manually, or you simple import an XML example of the XML you want to import, so you can let the system create the basic mapping. Next, you go over each element and specify:

• The Name (you usually don't change what the system created);

• The Namespace of the XML element. If you use namespaces, you can select them here or create a new namespace;

• Is it a repeating element? If so, you will get another property:

  • You can now specify the Target collection

• Specify whether the element contains:

  • a single value. In this case you can specify where you want to Map the content to. You can select a field that is defined in WEM;

  • nested values (<catalog> or <book> in the example above). When this element contains nested values, you can't specify a mapping, because you should specify the mapping of the elements that are contained in this element.

The data export node is used to export data. When this node is dragged onto the workflow, you will automatically get a popup window where you have to select a list or list filter as the source from which you want to export the data. Next you edit the properties, so you can control the data export. The following properties are available:

This node has two exits:

• Error- this exit is used when the export produces an error;

• Default exit - this exit is used when the data export does not produce any errors.

Edit mapping

When you want to export to Json or XML, you need to specify a mapping to map the exported data to either Json or XML. This works the same as specifying the mappong for data import (see above for a description of how to create a mapping). The only difference is that the mapping will now be used to export data from your WEM application to Json or XML instead of importing data into your WEM application.

When this node is reached, an HTTP request will be executed. The HTTP request node supports:

• All common request methods (GET, POST, PUT, DELETE, PATCH, etc.);

• Query parameters (expressions);

• Basic authentication and Client certificate authentication;

• Custom request headers (expressions);

• Custom response headers (mapped to fields);

• If applicable, a request body (text, file or richtext);

• Response body (text, file or richtext).

The type of request, and the HTTP request details are all specified in the node’s properties. Some properties are only needed for certain request types, as is displayed in the example below.

The properties:

The Web request node can have several exits. There are two pre-defined exits:

• Default exit

• Error

  This is the standard error exit for every WEM Node to catch technical code issues within the node itself to prevent showing technical error-details to end users. In this case it should not be used to handle Fault Messages from the Response (which are correct results within the HTTP Request Process - not errors - and have specific HTTP Response Codes which can be handled specifically)

Besides these pre-defined exits, it is possible to define an exit for every possible status code the HTTP Request returns. This includes any "error messages" or "fault messages" that the remote endpoint can provide.

HTTP Status Code Exits

The HTTP Request Node allows you to add exits for specific HTTP Status Codes (or response codes) that the resulting Response can provide. A link to a list of possible HTTP status codes and types/grouping is provided above and here: (wiki).

You should check with the provider of the remote endpoint to understand which Response Codes you may expect and could handle specifically.

When you define the Exit by HTTP Code, you currently have to define the specific code (there is no option for "wildcards" like 4xx and 5xx - but this may be provided in future). Then, following the specific HTTP Code Exit, you can handle it accordingly, and the Response Body can contain details of the specific situation so you may want to use that Response Body information as well when displaying feedback to user.

HTTP Status Code Exit or Error Exit?

Basically, you will not use the Error Exit to handle errors that occur on the Remote side - the Error Exit should only be used for situations where the Response is not received (there is no HTTP Status Code) - typically this is for when the Request itself is malformed and causes issues in the WEM Runtime. You should leave the Error Exit unlinked to show the technical information from the WEM Runtime that may indicate a bug or another issue that needs to be fixed. To make things confusing: that error may be displayed as a Server 500 (HTTP Status code 500) error, but this may be the status code from the WEM Runtime, and not from the remote endpoint...

HTTP Status Codes in the 4xx range are considered "client errors" and the 5xx range are considered "server errors" - in any case - if this status code is received in the Response object and there is a corresponding exit, this exit is followed and the Response Body will contain the detailed results from the remote endpoint. As this is mapped to a field in your model, you can just display that information or work some logic on its contents.

HTTP Status Codes 4xx and 5xx as received from the remote endpoint are valid Response Status Codes and are NOT considered Errors that will follow the Error Exit.

Change language

Function

With the change language process you can change the language of the user's session in the runtime. You can choose languages from the available languages configured in the project settings. You can find a list of all supported languages and their names in the available languages section.

Properties

For the change language node, we have the following properties:

How to use this node?

There are different ways in which we can implement and use this node, here we will show a basic example that you can later modify according to the need, and the ideas, that you want to implement in your project.

One of the easiest ways to use it:

1. Create a field with the Default Language. In this case we use en-US

2. Inside the properties of the change language process node you insert the datafield you just made.

1. Create an interaction that triggers the change language process, in this case we will use a button that activates the process

Flowchart

For the flowchart, connect from the start node to the interaction node where you want to change the language from. Next is to add the button exit "change" to the process node and connect the default exit back to the interaction screen.

Inside the node properties; put which language the project is going to change into, as the example below shows.

Change Timezone

Function

This process is to change the timezone in the current project. It is important when we handle several timezones within our project. WEM supports the IANA Standard Time zones and uses the tz identifier to name the timezones.

Properties

For the change timezone node, we have the following properties:

Flowchart

For the flowchart, connect from the interaction node to the change language node. In the following example we will be using the start node by default; an interaction node, and the change timezone node as shown below.

For the flowchart, connect from the start to the interaction node, from interaction to the change timezone node and back to the interaction again for the result.

1. Use an interaction node, and put the change timezone node next to the interaction node in the flowchart.

2. Create a field that hold a the timezone you want to change to or put the name in the process node properties.

3. Create an exit that will go to the node to execute the process and use the default exit to go back to your interaction node.

4. Add a button that triggers the exit in your interaction node and a label that shows the current timezone.

Confirm session changes

Function

Its function is to confirm if a session fields is changed and keep its information during this session without specifically making a post or other update (following an exit from a page). The node can be linked to an exit from another node and needs the default exit to have a next step. It will send the changes in session fields at the client/browser to store them on the server in the current session. Very useful in cases where a change in fields on a page can trigger an execute flowchart (containing the confirm session) but return back to the main page - in which case the session on server is not updated (that would only be when user follows an Exit) and the user wants to navigate away using a Navigation Item (without the Confirm Session, the changes will be lost to this session).

Sleep

Function

This function is to set a wait time before the runtime goes to the next node.

Properties

The properties allow us to connect the elements of our project to the process options. For this sleep node, we have the following propertie:

How to use this node?

The following example will show the time in seconds it takes to execute the action of the sleep node.

The objective of this project is basically to visually show the time that the process takes to execute the "sleep" time that is part of the configuration; The process is explained in detail below. For this example project, two values, one initial and one final, are compared, using the assignment of a function type date to give a parameter between both fields. Initial date that starts from one point and ends at another; between this space the time of the sleep node process is calculated.

1. The interaction node.

2. Add an assignment node with the advanced function "now()" that will compare the first number.

3. Add an assignment node with the advanced function "datePart", that will have the start date day, which will compare the first number.

4. An overlay is added to show the executed process in progress.

5. The sleep node has been added with 3 seconds in its property max time.

6. Add an assignment node with the advanced function "now()", that will compare the second number.

7. Add an assignment node with the advanced function "datePart", that will have the end date day, which will compare the second number.

8. The next assignment node will receive the information of the time.

Node operation process.

Describing the process of the flowchart in the preview. Detailed after executing the project.

1. Before clicking the sleep button.
2. The processed overlay, while the node is been executed.
3. The result of the compared fields within the time and sleep process node.

Redirect

Function

This processes is to redirect the user/browser to a specific url - without the need to let user click a link to go there. In this use case, we will be showing a simple way to use it, just as an illustration.

Properties

The properties allow us to connect the elements of our project to the different process parameters of their function. For this redirect node, we have the following:

How to use this node?

For the flowchart, connect from the interaction node to the redirect node as shown below.

One of the easiest ways to use it:

1. Use an interaction node, and put the redirect node on the canvas.

2. Create an exit that will go to the node to execute the process.

1. Set up the redirect node properties to a string with the url you want to point to. The property field is a expression and can be used with a text datafield, with expressions or directly with an url string. This example uses "www.google.com" as string.

Node operation process.

1. Before clicking the "redirect" button, which also is shown as button most of the time.

1. Then, you will go to the URL set, in this case, "google.com"

Webrequest

Webrequest, is the legacy version of the "HTTP" node , which connects with any action of request, get, put, post, delete, etc... This node is updated to a more user-friendly way, for more information about its improvement, you can visit the documentation page with more details.

Resize image

Function

This node is to change the size of an image. When the image is resized, it is scaled to the size best representing the given size property keeping the original scale. This process can be used to decrease image sizes before you add them to files like pdf's or to lessen the file size to restrict impact on performance.

Properties

For this resize node, we have the following properties:

How to use this node?

For the flowchart, connect from the interaction node to the change language node and use the default exit to go to the next or back to the same interaction node.

an example:

1. Create a temporary file field to put the image you want to change and a field for the result.

2. Use an interaction node where you select the image, then we put the Resize Image node.

3. Create an exit that will go to the node to execute the process and use the default exit to go back.

4. Set the node properties,

Node operation process.

1. Before clicking the resize button, the image set is shown with the original size. We can see that the image is quite large at the beginning before executing the resize image node.

2. After clicking the resize button, the image gets the sizes set and the label shows the result. This image has take the size and height fitting closest to the node properties.

Flatten CSV Document

Function

This node is to Transpose CSV data into a new CSV that contains 3 columns: RowNumber, Column and Value for every "fieldvalue" in the original CSV.

Properties

How to use this node?

In the example we have a TEMP 1 field, this holds the resulting csv file, a overlay interaction node where we select the file we want to flatten and give us the resulting file and the process node.

One of the ways to use it:

1. Use an interaction node, then we put the convert Flatten CSV document node.

2. Create a temporary file field that will be the one that receives the converted file.

3. Create an exit that will go to the node to execute the process and connect back to the interaction node to show the result.

Node operation process.

1. Before clicking the flatten CSV button select the file.

2. After executing the process, the temporary field appears with the resulting file.

Extract text from document

The extract text process node is for extracting text from readable text files. The process works for .pdf and .docx files with properly made text. Images of text (in documents) instead of readable text can not be extracted.

properties

How to use this node?

1. Create a transient file field that holds the source file and create a text field for the return text.

2. Open or create the flowchart that performs the process.

3. Add an interaction node for selecting the source file and to show the result.

4. Add the process node and select the extract text process.

5. Connect the start node to the interaction node, then create an exit "extract text" for the interaction node and connect it to the process node.

6. Use the default exit of the process node to return to the interaction screen that now shows the result.

Now open the interaction node to design a quick screen like the image below. On the left a window for selecting the source file and trigger the process, and on the right a label with the respons text.

When you run this in the preview, this is the result:

Rename file

The rename file process is a feature to change the filename of a single file field. The input is an expression for the new name. You can use this for a static name by just putting some text in, or use an expression to generate a filename based on other information. The rename file process can be used to change the filename of multiple files in a list, using a loopnode You should add a check if the filefield to be renamed exists, before entering the process node.

The File Property (a WEM File Field) is used for both Input as well as Output: it is the same field, the same file that will get the new Name as its FileName property after the change.

Properties:

How to use this node

In this example I will be changing the name of all the files to the [ID] name of their respective row.

1. Open or create the flowchart that perform the process

2. Add a interaction node for starting the process to show the return

3. Add the process node and select the change file name process and add a loop node to go trough all the items in a list containing a file field. Fill in the properties of the node. In this case the file field from the datalist "webshop" for the input and output of the file.

4. Connect the start node first to the interaction node, then create an exit "rename file" for the interaction node and connect it to the loop node and that to the process node.

5. Use the default exit of the process node to return to the loop node and the end of loop exit to return to the process node.

The interaction node only activates the process, this does not need any user input besides running it. If you are not sure every row has a file, you should add a decision node between the loop and the process that goes back to the loop if there is no value (use HasValue or IsEmpty functions).

If your project has Webservices defined (consume and/or expose), you can access these services through the Service request node. The Service request node sends or retrieves data using a web service. The node itself does not handle any data, so you will need e.g. assignment nodes to store and work with the data. To use the node, you drag it onto the flowchart and a selection popup appears.

Here you select the webservice you want to use.

There are only two properties for this node:

• The Name, which is set by WEM and cannot be changed;

• The possibility to clear all input after the call to the webservice is finished. This is done through checking the checkbox for this option.

The node has a number of exits:

• Error - this exit is used if an error occurs using the node;

• Default exit - the regular exit when there are no errors

• Additional exits are possible if the webservice has predefined faults. If so, these are also exits for this node. And these exits help to better identify a problem if the node produces an error.

Example: when you want to call a webservice to retrieve data, you call that webservice through the node, and the data that is returned is stored in either data fields or list fields. Often a call requires input, in that case you start with one or more assignment nodes to set the input, than the service request node does the call to the webservice, and finally you use one or more assignment nodes to store the data that was retrieved using the service request node.

A complete documention on webservices can be found here:

WEM comes with a large number of pre-defined processes that you can use in your workflow. These processes range from generating documents to sending email or sending data to Google Analytics. When this process node is dragged to the flowchart, a popup window appears where you select the process that you want to use. If you select a particular process you will immediately see which input parameters are availble/necessary for this proces. An example:

Note: By default, no processes are available: you need to define which processes are available through the Project settings for Processes

Once you have selected the process you need in your flowchart, the specific properties become available to configure.

The properties are similar for all processes:

• Name of the node, this is set by WEM and cannot be changed.

• The specific Input parameters for this process.

• The specific Output parameters (for example when a PDF is created, in which File Field to store the result).

• The template that is specific for this process (e.g. the email body in case you want to send an email. You can edit the template by clicking on Edit template. Not all processes have a template, so you will only see this button when a template is available.

An example of the input parameters for the "Send email" process:

On the left is the input parameter name, in the middle column the data type and the right column shows the value, mapped field or expression when entered. On the far right is a button that takes you to the expression editor where you can enter the value for the parameter.

This node has two exits:

• Error- this exit is used when the process results in an error;

• Default exit - this exit is used when the process does not produce any errors.

The data export node is used to export data. When this node is dragged onto the workflow, you will automatically get a popup window where you have to select a list or list filter as the source from which you want to export the data. Next you edit the properties, so you can control the data export. The following properties are available:

This node has two exits:

• Error– this exit is used when the export produces an error;

• Default exit – this exit is used when the data export does not produce any errors.

Edit mapping

When you want to export to Json or XML, you need to specify a mapping to map the exported data to either Json or XML. This works the same as specifying the mappong for data import (see above for a description of how to create a mapping). The only difference is that the mapping will now be used to export data from your WEM application to Jsonor XML instead of importing data into your WEM application.

The ping server node is just what is sounds like. You can use the ping server node to ping a specific server and look for the right response. This can be used to check if a specific server is reachable and responding for example.

In WEM it is possible to generate messages, and listen to message. Based on these messages a specific action can be taken (e.g. write to a log or display popup on all user's screens). This happens in realtime. And to use this functionlity, you need the realtime message node:

• You need a node to send a message;

• You need one or more nodes to listen to messages ("Chanels");

• You can use a node to stop listening.

The properties of the node define how the node will behave: as a sender or a listener. Let's look at the various properties. For the various node "Actions", there is a different set of properties. Three properties are always available:

• Name: the name of the node, which is set by WEM and cannot be changed;

• Channel name: this is the name of the messaging channel you want to use. You are free to give it any name you want, as long as it is unique within the application. When you are listening to messages, or want to stop listening to messages, you need to specify the name of an existing channel;

• Action: This property defines how the node will behave:

  • Start listening - the node will behave as a listener on a particular channel;

  • Send message - the node will now behave as a sender on a particular channel;

  • Stop listening - the node will stop the the listening on a particular channel.

Depending on the action, the remaining properties vary.

Start listening

Send message

Stop listening

This node has two exits:

• Error- this exit is used when the node produces an error;

• Default exit - this exit is used when there are no errors.

A note is not a node like the ones described before. a note is exactly that: a notation that you can drop on you flowchart. You could use this to explain the flow, place it behind a part of the flowchart to highlight that part, etc.

You can have multiple notes on you flowchart.

Using this node is the way to realize single sign-on in WEM. Let's say the authentication provider is Microsoft Active Directory. When the user is already logged into the company network, the authentication node will recognize this and won't ask for a username/password. If the user has not been logged in, he/she will be asked to log in. When this is done, the user is logged onto the company network, so all other applications that use Active Directory will recognize this as well.

The authentication node can be used to authenticate a user, using a pre-defined authentication provider (). Using this node is simple: drag it to the workflow where the authentication needs to take place (e.g. the Home flowchart) and make sure the workflow passes this node. Once the node has been reached, the pre-defined authentication provider does the user authentication. There are a few properties:

The node has three possible exits:

• Authenticated - in this case the user is authenticated

• Not authenticated - the authentication failed or the user is logged out

• Error - the authentication resulted in an error