The environment that makes your application available to your users
The WEM Runtime environment is a web-based application platform that is specifically built to interpret WEM Portal Definitions as they are created in the WEM Modeler, and serve them as specific web applications.
The WEM Platform does not generate code like other (low-code) platforms do (which in turn needs to be deployed/installed/configured). The WEM Runtime itself IS the compiled and deployed code, secured, optimized, scalable and compartmentalized using micro-services. It is already up and running and available to accept new or changed Portal Definitions. The WEM Portal Definitions that the Runtime uses to transform into operational web applications, contain the necessary resources which are compiled and distributed from the Modeler to the targeted Runtime environments by the Publish Process. The Runtime retrieves the information from the Publisher and loads the new definition to start serving it as your application.
The WEM Runtime generates currently standard Responsive HTML results, using JavaScript and AJAX, so WEM Portals can be used in any modern browser (Edge, Chrome, Firefox, Safari, Brave, Opera) on any operating system (Windows, Apple, ChromeOS, Linux, Android, iOS).
The WEM Runtime can support hundreds of Portals running simultaneously side-by-side.
The WEM Runtime Platform itself can run on different environments, it can also run on a Private Cloud (Azure, AWS). The WEM Organization provides support and guidelines in setting up the Runtime in Private Clouds.
The WEM Runtime consists of two instances, called Staging and Live. Every instance of the runtime has its own database, so the live environment keeps the users data.
Staging: Typically used for review and acceptance testing with a (limited) group of testers/users, as a step between Application Development (Modeler) and Live/Production.
Live: Typically used as the final production version.
To get your application from the Modeler to the Runtime environment the Publish Process is used which will be explained in more detail on the next page.
The WEM Staging Runtime Environment - between Development in Modeler and Use in Production
The first instance of the WEM Runtime is the Staging Runtime. When publishing a project it will always first transfer to the Staging Runtime. The WEM Staging Runtime is typically used for review and acceptance testing with a (limited) group of testers/users, as a step between Application Development in the Modeler and Usage in Live/Production.
The default URL for the staging environment is https://[projectname].staging.wem.io. and can be changed in the portal settings. More about changing hostnames can be found here: #manage-hostnames.
Every environment (Preview, Staging, Live) has its own database. When publishing a project to a new environment you publish the data structure only, NOT its data content. This is necessary to keep the right data in your live environment. When your storage strategy is set to All portals share the same database
you still have a different database for Staging and for Live used by both portals. More about this here: #storage-strategy.
Before you publish your project to the staging environment you need a valid license. This is a license from WEM giving you permission to publish. You can find out more about licenses here.
The WEM Live Runtime Environment - your Application in Production
The WEM Live Runtime is the Production Environment for your application. In the Publish feature you can activate both Staging and Live in one go. All settings and features in the Modeler are published first to Staging and updated in Staging Environment, and then to Live and updated in the Live Environment. Publishing is needed when changes are made in the Modeler that need to be implemented in Live Runtime. You want to publish only the finished and tested updates to this environment to make sure you keep a working application exposed to your users.
The default URL for the live environment is https://[projectname].live.wem.io. and can be changed in the portal settings. More about changing hostnames can be found here: #manage-hostnames.
Every environment has its own database. When publishing a project to a new environment you publish the data structure not its content. This is necessary to keep the right data in your live environment. When your storage strategy has all portals share the same database you still have a different database for staging and for live used by both portals. More about this here: #storage-strategy.
Before you publish your project to the live environment you need a license. This is a license from WEM giving you permission to publish to live. You can find out more about licenses here.
Getting your application on to the WEM Runtime Environment
The Publishing Process transfers your Project from the WEM Modeler (your development environment) to the WEM Runtime environment to make it available to your users.
Publishing works in a flow from Modeler to Staging to Live, as depicted in the diagram.
From Modeler To Staging Only You can choose to publish to Staging only: this will leave the Live Runtime unchanged, and sends the current situation of the Project in the Modeler to the Staging Runtime. This is what you usually do when you are done making changes and want to test in Staging with realistic data or provide a new "review/acceptance" version to your users.
From Staging To Live Only You can also choose to publish to Live only: this will take the current version on Staging and sends that to the Live Runtime. This is typically what you do when the Staging version has been reviewed and accepted, and this version should become the new Production version. It will NOT push any changes made to the Project that have not been published to Staging.
From Modeler to Live always goes through Staging Or you can choose to publish from Modeler to Live, but this will always go through Staging! All changes done in the Modeler will be pushed to Staging first and immediately after Staging also to Live, in one go.
The Publishing Process gathers all resources and settings from your project in the Modeler, transforms it into the Portal Definition as needed by the WEM Runtime environment, wraps it into a compressed file and sends it to the Staging Runtime Environment. The Staging Environment receives the new package, unwraps it and replaces the old Portal Definition with the new version.
You may be working together with other WEM-users on your project, so if you start a Publishing process while others are making changes as well, this requires some form of coordination. The WEM Platform takes care of this! When several WEM users are working on the same Project, the Modeler will send updates from every user - when they get saved in the backend - to every other user using Comet technology. So every user will have the latest version of the Project available in their browser.
Check settings When someone starts the Publishing Process, that Process will first check all current project settings.
Acquire Publish Lock "There can be only One" ... active Publishing Process running for one Project. So one important step is to check if nobody else has started a Publish action. If it is free to publish, a Publish Lock will be set on the Project, so when someone else attempts to Publish - it will be blocked with a message showing that the Project is already being Published.
Create logging entries The Process will store information about all steps, so in case something fails along the way, this information may be used by WEM Techs to investigate and resolve the situation if necessary.
Update Portal Packages All resources in the Project needed for Publication are gathered for each portal.
Publish portals to the selected Runtimes Based on selection as previously described: first to Staging (if selected), then to Live. The following steps are not shown in the image - but available to you when you publish - you can expand the steps in the Publishing Process Overlay:
Upload package to target Runtime environment;
Validate the package;
Store the package;
LOCK portals*;
Update database schema;
Update Portal Definition;
Commit package;
RELEASE portal locks*.
Finish logging All information gathered during the process is combined and stored in the database.
Release Publish Lock All done, release the lock so other users (or yourself) can start a new Publish actions. If something fails during the Publishing Process, there is a final fallback scenario in place that will release a Publish Lock after 15 minutes since the last recorded action within the Publishing Process.
People may be actively using the application when you want to publish the new version, so in order to perform the update without disturbing active sessions - AND make sure that the Publishing Process can be executed without being disturbed itself, the Publishing Process places a Lock on the Portals. This means that no new requests can be made and no changes to data will be stored. All running requests will be handled until finished. As soon as all work is done, the Lock is released and all requests to the Portals can be handled - using the new updated version.
To make sure that this Lock is only active for the shortest possible time, the Publishing Process does all preparation that is possible before placing the Lock. Most users will only notice a very slightly slower response to their action while working in the application when this Publishing Lock is placed and released.
The Publishing Process tries to find a window of opportunity to place the lock and continue the Publishing action, but it only tries to find this window for a short period of time. If this window cannot be retrieved within the allotted time, the Publishing Process will stop and return the message that it Failed to acquire a lock. The Portal will remain in use without changes and you should try to Publish again at a later moment. Failing to acquire a Portal Lock may be caused by long-running actions, like importing large amounts of data or trying to execute a very complex query against a very large dataset. If this happens more often, it may be required to optimize these actions in the Modeler by improving your flows (splitting it into steps by putting interaction nodes in between them to make room) or optimizing your queries to let them work faster. Doing this may not be easy or straightforward, but you can always ask for support in MyWEM...
When you have started the Publishing Process, the Publishing Process Overlay shows the various steps and will show which step is currently active - or place a green check-icon to indicate a step is successfully done.
Depending on the size of your project - the number of resources to gather, the checks to perform, the size of the Package to distribute, the number of database changes to perform and other elements - it may take a while for a Project to be Published. It may take a few minutes, but in some cases maybe even 15 to 20 minutes.
You do NOT have to wait and keep the Publishing Process Overlay open for all that time!
Once you have started the process, it runs independently of your browser session. You may close the overlay and the process will continue in the background, you can even close the Modeler - Publishing will continue until it's done (or failed).
If you keep the Publishing Process Overlay open, you can see which step is active and which step is successfully finished. The progress updates are provided using Comet messages from the WEM Platform to your browser as long as the Comet "channel" is available. If you close the overlay or close the Modeler the channel is closed, but the process continues. If you re-open the Modeler and hit the Publish button again, you will see a [Show History]
button. Click this button to see past Publishing actions. They may show:
Running (icon of a running person): You or someone else has started a publish process which has not yet been completed (Publish Lock is in place); Nothing else to do but wait until it is finished (or just continue making changes to your project for the next version);
Finished successfully (green check);
Failed: In this case you can click on the item to see some information about the failure - like failing to acquire a portal lock.
In case of failing to acquire a Publish or Portal lock: close the window, wait a few minutes and try again. Maybe even close all open tabs and reload the Modeler, just to be sure (although refreshing the Modeler will close any open tabs you may have been working on, but that is a good thing if publishing fails anyway).
In case of other failures in the Progress Steps, or even in case of a Running situation that does not seem to stop (for more than 15 minutes), just wait about 15 minutes and try again. Very often it will succeed! Also in this case: maybe even reload the Modeler before you try again...
If the process fails and you have chosen the option to publish to both Staging and Live in one go, you may try to publish to Staging alone first and see if that succeeds. Then do the Publish action from Staging to Live only and see if that succeeds.
If the Publishing Process keeps failing after several tries (with enough time in between) or if the Failure Message is NOT about failing to acquire a lock and the failure information is of no help at all: go to MyWEM and create a Support Ticket - WEM Support will surely be able to help!
Tip: to speed up the Support process, provide the Project ID, the details of the publishing overlay (as a screenshot). Also indicate if you allow Support to perform a publishing action to staging and/or live if they want to check/test, or if you explicitly do NOT want Support to try and start a publish action.
When, after more than 15-20 minutes after the Publish Process has started, it still shows Running in the History, you could start another Publish Process. That action will tell you if the previous Process is indeed still running - but more likely it will just start a new Publish Process.
If this happens quite regularly in your specific project, please let it know in a Support Ticket, mentioning your Project ID (the numeric value in the browser's addressbar after ?project=...
).
If the process seems to keep running , even after more than 15 minutes, it may be that the feedback from the Publish Process back to the Modeler is not able to send back the "successful end" message in time.