Create tasks for automated and scheduled execution
WEM-Native Automated/Scheduled Tasks using this Task feature is available only on full-Kubernetes Private Clouds.
(Automated) Tasks can only perform Action Flowcharts, they can not have any User Interaction Nodes. These Task Action Flowcharts must have a Start Node and one End Node. In between they can contain other Action Flowcharts and any node that does not require user interaction. See image below for an example of an Action Flowchart that will be used as a Task and see that nodes with User Interactions are unavailable because the type of flowchart is Action Flow - which you can indicate when you create a new flowchart.
When you have created your Action Flowchart(s) that you want to use as Tasks, next step is to define your Task so it can be used for scheduling. In the Navigation Pane you can find the Tasks folder. This is where you define Tasks in your project with a Name, a Description and most importantly the Action Flowchart that should be executed when the Task is run.
This now needs to be published to the WEM Runtime (running on a WEM Kubernetes Cloud) to make it available for tools that can schedule these tasks on that WEM Runtime Environment.
The Task Scheduler is a specific micro-service as part of the WEM Kubernetes Runtime Environment and is responsible for storing and managing the Schedules, as well as executing the Tasks according to those Schedules. Executing Tasks is done on specific threads within the Kubernetes Runtime and mostly separated from the normal Portal usage (like users accessing the portal in their browser). This way, Tasks may run quite long, as long as they need and the Task Scheduler Service will keep it running as needed. So it is very important to make sure that the Task to be performed, is properly tested. Any issues with Task executions may be found in the logs (also available in the DevOps portal).
A WEM Kubernetes Runtime Environment provides several secured API endpoints to support certain DevOps-related features. Scheduling Tasks is one of those API endpoints with which the Task Scheduler micro-service can be accessed to manage Schedules.
The WEM Platform provides the WEM DevOps Portal, a portal created using WEM Modeler that can access the Kubernetes Runtime API Endpoints and make it easy to use. This DevOps Portal is only available to people who require access to their WEM Kubernetes Runtime Environment to use certain WEM-Related DevOps features. Scheduling Tasks in portals running on that environment is one of those features.
If you have access and permissions to schedule tasks, you can to go to the Portals Section in the DevOps portal, find the portal in the list and click the Action button to access the portal-specific features - where Scheduled Tasks is what we're looking for now.
The DevOps portal will access the Portal Definition on the runtime to retrieve the available Tasks as defined and published earlier.
Every task can get multiple schedules, as you can see in the image. The selected task has 6 defined schedules, which are examples of the various schedule types. You can also see if a schedule is enabled, when it was last executed and when the next execution is planned.
Available Schedule Types are:
One Time
Daily Recurring (time of day or recurring)
Weekly Recurring (with daily options)
Monthly Recurring (with daily options)
Each Schedule Type provides specific fields to define the schedule. See some examples:
At the creation of Schedules for a Task, the schedule will be Disabled by default unless you switch the Enabled option. A disabled schedule will not be executed, but the definition will be available. You can always Enable and Disable a schedule later via the specific Schedules Details page.
On the Schedule Details page, you can see the information about the schedule as well as perform following actions:
Switch between Enabled and Disabled using the Play/Pause button.
Get Current State: this action will ask the Task Scheduling Service for the current state of the specific task. If it is currently running, it will show.
Run Task Now: this action will execute the task immediately regardless of the schedule definition - useful for testing.
Delete Schedule: will completely remove the schedule definition and the task will no longer be executed. A warning will be displayed to ask if you really want to delete the schedule definition.
Edit Schedule: to change the schedule definition, including type and all other type-specific settings.
Rename Schedule: the Name of the Schedule is part of the Task Scheduler Endpoint - renaming it is therefore a specific action that also needs to be sent to the Task Scheduler service.
If you are looking for ways to automate and schedule tasks in projects that do not run on a Kubernetes Runtime (like the current Public Clouds in Europe and APAC), read this post on our WEM Forum about using EasyCron
To create a new schedule on a specific task, click the calendar-button . To edit an existing schedule, click on the schedule-row.
The Navigation-tab is where you manage your 'Navigation points'.
Introduced in June 2022, Custom HTTP Endpoints can be managed from this Navigation-tab.
Navigation points are basically menu options that are available in the various menus that are available in a WEM application. A navigation point navigates towards a specific flowchart or URL. This is defined when you create a navigation point.
Every WEM application comes with three different visible menu-groups and one invisible group. The location and styling of the visible menu-groups is defined by the Design Template selected on the portal.
Main menu - this is the main menu bar that you usually find at the top of your application (or at a different position defined by the Design Template).
User menu - this menu is also on the top menu bar, but at the far right: here you find all navigation points (menu options) that can be made available when a user has logged in (a typical use for this group). But this group can also be used just to show specific menu items at the top-right of the page (or where the Design Template places this group).
Footer menu - which is actually a secondary menu that can be positioned at the bottom of the page but also at the left (based on the location defined by the Design Template).
Besides the menus that are mentioned above, there is also a group called Invisible. This is a special one: all navigation points that are part of Invisible are points that will not be visible in a manu on the page, but may provide specific URLs (hostname of portal + path to specific flow). These URLs can be used to directly access a specific flowchart in the WEM application from the outside (bypassing the standard home-starting point). For example by providing a link in an email message. A specific often-used example is the Reset Password option: you create a URL that is very specific, you can't access the functionality via the application directly, but through the URL you could access the password reset functionality of the application (for example via link in email). This feature can be seen in the Quick Starter Project Basic Authentication v2020, in MyWEM.
A navigation point navigates directly to a flowchart or a hyperlink. Usually, a navigation point is used as a menu item in a menu. When you click on a menu you get access to the list of navigation points. When you right-click on a navigation point, you get a menu to manage the navigation point:
To create a new navigation point, click on the menu or navigation point where you want to create a navigation point. When you create a new navigation point, some properties have to be defined:
Hierarchical parents of a navigation points override the visible when expression of its children. When a parent is not visible to the user its children will also not be visible and its direct link will not allow access either.
Most Navigation menu-bar options are pretty straightforward:
Move allows you to move a navigation point to another menu;
Delete deletes the navigation point;
Find usages show you where a navigation point is used within the current project.
Rename Your navigation point, this is updated project wide.
Query parameters are parameters that are used in URLs. Let's look at this example URL (that does not specifically work):
http://queryapp.live.wem.io/queryparam?uid=admin&action=resetpw
This URL points to the navigation point "queryparam" and contains two parameters: uid and action. Both have values associated with the specific parameter. The flowchart associated with the navigation point "queryparam" gets direct access to these variables and their values through the data-field-mapping you define. To make a parameter available to a navigation point, select the navigation point and click on Edit query parameters. You now get a form where you can manage the parameters for this navigation point:
You can now add or delete query parameters. When you Add a new parameters, you have to select the field to which this parameter should be mapped:
The WEM modeler automatically assigns a name to the parameter, but when you click on that name you can change it to your own preferred name (this is the name that is used in the URL). When you want to change the data field, simply click on Change data field.
You can also define Query string Parameters on the Project level, in Project Configuration - Query string, to make them available to any and all URL paths. When these parameters have been used on any URL to access the portal, the mapped data fields will have the provided values and are available to your flows.
Custom WebHooks into your application
Custom HTTP Endpoints are currently (June 2022) only available in Private Cloud Runtime environments. This feature will not be available in the current Public Shared Cloud.
So, while you can already define your Custom HTTP Endpoints in the Modeler for your Project, they will only actually work when your portals are running on a Private Cloud Runtime!
With these Custom HTTP Endpoints, WEM provides yet another way to make integration with other applications possible. Other integration features available are SOAP/XML, REST/JSON, OData, SAML, OAuth and information about those features can be found in the Services and Integration section.
HTTP Request Messages can be sent using different methods [wiki]. Other applications may be able to send those messages in order to get information out of your WEM Portal or make changes to your data.
Please make sure that wherever you can enter names for parameters, you use URL-Safe characters (read this post on stackoverflow).
In Tab Navigation, element HTTP Endpoints, click the [...] button to open the context-menu and click New HTTP Endpoint.
The URL Path is a templated path containing literal (fixed) parts and parameter (dynamic, replaceable) parts. The hostname part is automatically implied for each portal and all the configured hostnames published to the runtimes, so in this field you only have to enter the path that starts after the hostname:
https://portal.wem.io/CUSTOM_URLPATH.
Parameters are surrounded by curly brackets: {parameter}. In the example below {order-id} is a parameter part named order-id as part of the URL-Path.
Example: order/get/{order-id}
Parameters can be bound to a target data field. As soon as you type a parameter part {curly-brackets-with-parameter-name} , the name between the curly brackets will automatically be added to the list of Parameters for the URL Path. At runtime, when the path is requested, the value at the position of the parameter will be written to the target data field as defined in this part.
Query Parameters can also be added in the Parameters section, to add additional parameters that will become part of the additional query string. The Query String is the part in the URL that starts with a question mark ? and is followed by name=value pairs, separated by an & ampersand. A Query string is considered not as a part of the URL Path itself, but as an addition to the request to said path. The path defines the resource (location), the query string adds elements for specific logic on or within that resource.
The HTTP Request Method (wiki) indicates the method (or verb) of the HTTP request expected by the endpoint. If this is set to “None” then the endpoint does not accept any request on this specific path. Endpoints with a “None” method are used as part of other endpoints.
GET: request to retrieve data without making changes in the portal;
POST: request body is required with payload (data) that may trigger changes in the portal;
DELETE: request to delete the indicated resource;
HEAD: request to retrieve only the header information for a request (no response body); used for checking availability of a resource or content-length of a file
OPTIONS: request to provide the HTTP methods that the portal supports;
PATCH: request to perform a partial update with the provided information in the request body;
PUT: request to create or update a resource with the information provided in the request body;
None: to indicate that this path will not accept requests to this specific path, but it may be used as a (re-usable) part for other endpoints
If this option is checked and any validation error occurs, an exception is thrown and the request is not further handled.
Some validation errors:
Missing request body (required for methods POST, PUT and PATCH);
Missing required parameter value;
Multiple values provided for a parameter;
Value conversion error. The raw value could not be converted to the expected datatype of the data field;
Value out of range error. For example, integer value falls out of allowed range of the numeric data field.
Value format error. For example, if raw value does not conform to the format of a valid email address.
By disabling this option, the endpoint will continue with the flow, but the mapped fields may not have valid values (so you may need to perform your own checks and validations additionally).
This option indicates if a WEM Session should be used when this endpoint is targeted.
Typically used for API integration, like REST/JSON: basically 2 applications exchanging messages/data in a single interaction. There is no session required, no specific user, no specific process with consecutive steps that need the data from the first interaction onwards.
Typically used in WEB-HOOK situations.
When a user (via browser) is already active in the Portal (active session), or if a new session should be started and the provided data in the request should be used and made available in consecutive steps, so you want to be able to continue in the Portal with the externally triggered changes.
One typical example is when using external payment providers, that typically prescribe a certain Web-Hook they use to send the transaction results, you want to retrieve that and link it specifically to the active session.
This option becomes available when the selected HTTP Request Method is one that requires a Request Body: POST, PATCH, PUT.
If this option is enabled, the form-fields within the request body will be converted into a JSON structure, making it easy to use the Import JSON Node to map these form-field-values to WEM-Fields in the Data Model. The conversion will be executed to BEST-EFFORT. The providing application may provide form-fields in a way that is not easily correctly converted into JSON, especially when they use custom ways to group multiple fields (array/indexed).
This option becomes available when the selected HTTP Request Method is one that requires a Request Body: POST, PATCH, PUT.
Put a Data Field into this input to map the contents of the Request Body (from the POST, PATCH or PUT request). This field can be Text (for form-fields, json, or other text contents) or a File (to exchange binary files - directly map them from and to WEM File Fields).
WEM can automatically generate OpenAPI Documentation for your custom HTTP Endpoints. The resulting OpenAPI documentation can be accessed when the Custom HTTP Endpoints are available in the Staging or Live runtime environments (so after publishing), by using the following link:
{your-portal-hostname}/openapi
This url or its resulting JSON can be used in other applications that can visualize or generate client code based on OpenAPI documentation. Swagger is a well-known tool to visualize this information.
In this part you can provide additional information that the OpenAPI documentation will provide.
Endpoint name
Name used in the OpenAPI document generated for the endpoint. This name is used as method/function identifier by tools generating client code for calling this endpoint.
Description
This description is included in the OpenAPI document generated for the endpoint. With this description you can provide further detailed information about your custom endpoint to the consuming party.
Source column indicates in which Request-element the parameter is located: URL Path, Query string, Header or Form.
Name is the name of the parameter to be used. Make sure these values are URL-Safe (read this post on stackoverflow)!
Required can be used to force a check on the existence of the parameter in the Request, and send a validation error if it is missing.
Target data field is where you map the incoming values to their respective fields in your Data Model, so you can work with the values in flows and pages.
Inherited by nested endpoints allows nested endpoints to inherit this parameter so you only declare and map it once, and it is available to all deeper levels (nested endpoints) and the flows therein.
[URL-Path] Parameters which are dynamic parts of the URL Path can be added using the curly brackets {param-name} into the URL Path. They then get automatically added to the Parameters section so you can map them to the Target data field.
[Query string] Query string parameters can be added by clicking the button “Add query parameter”. You can define the Name as it should be used and please make sure these names are URL-Safe!
[Request Header] Request header fields can be added specifically using the Add Request Header. For a list of available http header fields, check this wiki link. Some Header fields may only contain specific values and the number of fields and length of values is limited.
[Form Fields] Form fields allows you to define specific HTTP Form Fields that can be mapped to WEM Data Model fields. These fields are only available when using verbs that require a Request Body: POST, PATCH, PUT.
Every HTTP Endpoint that can handle a request (with any other method then “None”) has a flowchart. Once you've created (and configured) the Endpoint, the Flowchart is accessible by double-clicking on the Endpoint in the navigation tree, or by clicking on the Open Flowchart option in the context-menu.
Typically, an HTTP Endpoint Flowchart does not support Interaction Nodes so in fact should be considered to be an Action Flowchart (without user-interaction). It must always end with either an HTTP Response Node, a Navigation Node or a Clear Session node (that also performs a redirect at the end).
The Flowchart Nodes pane has a specific Node to provide the HTTP Response: 
.
When used in API Integration (server-to-server), it should provide an HTTP Response consisting of an HTTP Response Code and optionally a Response Body.
When used as Web-Hook where a redirect is part of the process provided to the user, you can use the Navigation node to send the user to other parts of the application when this Http Endpoint Node is activated. When the option to use the WEM Runtime Session is active, this navigation will use the existing session.
| Property | Description |
|---|---|
Name
The (internal) name of the navigation point.
Display text
(optional) This is the text that is used for a menu item (navigation point) in your application. If this property is left empty, the Name property is used to display the label of the menu item.
Icon
(optional) It is possible to have menu items that also include an icon. Here you can specify the icon.
Visible when
This property is required.
You can restrict access to a navigation point by specifying an expression in this property. If this expression evaluates to false, the navigation point is not visible and its flowchart not accessible by its URL path. This is often used to give access based on a specific user role or set of user roles. But any other reason can be used to prevent access, as long as you can specify it in the expression editor.
For security reasons, this field is required: you have to consciously set the Visible When expression! Plainly setting the expression to true makes the item always available - so you can use that if you are sure that this item does not need specific rules to be available - just as long as this choice is consciously made.
Action
Deeplink: The navigation point navigates towards a flowchart that will be executed after clicked on menu item. This action should be a stand-alone flow ending in an Interaction Node without an End Node (or a navigation node navigating to a different flow).
Subroutine: This can be used to call flowcharts as a subroutine, to return to the same point when this item was clicked. The flowchart to be executed must end with an End Node, so that when flow reaches the End Node it can return to the point from where the Subroutine was started.
Hyperlink: Allows you specify a URL you want this navigation point to use. This is usually an external URL pointing to another webpage.
None: No action will be executed and this option allows you to create deeper level menu items (submenu). None creates a placeholder in the application menu that can expand and collapse to show/hide submenu items. After creation of this item, you can create new navigation points as sub-items in this item, that will be available if this item is clicked to expand the sub-menu.
Flowchart
Only available when the Action is Deeplink or Subroutine. You use this field to select the flowchart the navigation point will execute.
Hyperlink
Only available when the Action is Hyperlink. This field is used to specify the hyperlink the navigation point will take you to.
URL Path
Only available when the Action is Deeplink or None. The specified path is added to the base hostname of the portal and can be used to get direct access to this navigation point through your browser.
Open hyperlink in
When you use a hyperlink as a navigation point, you can specify what should happen when the hyperlink is opened: Open in a new window, open in the current window, open in the current frame or open in the parent frame.
Name
the name of the response and is used in the generated open API document
Content type
Provides a value for the Content-Type HTTP Response header. Check [wiki] for common examples.
Status code
Provides a value for the HTTP status code of the response. Check [wiki] for possible status codes - specifically 418.
Response body
Provide value for the data which is sent back to the caller. This should match the defined content type.
Response headers
To allow for the configuration of HTTP response headers. Check [wiki] for standard response values.
