WASM builds

Build automat applications into WebAssembly (WASM) to run them in web browsers. This allows you to create wasm applications with the same codebase as your web applications.

There are some limitations to be aware of when building for WASM:

  • JS loading by default in ‘blob’ mode, which means that all js code is loaded in a single blob, and it does not change in an already loaded wasm application. This behaviour can be changed to ‘per-template’ in the builder settings, but it is currently experimental and may cause issues with already built applications that were built for the blob style mode.
  • B2B features work differently as it cannot contact used API’s directly (no access to erply session key). It uses a special proxy on the server to handle the request. This also means that the applications needs to be installed on the server as well for authentication and security purposes.
  • Severe bottleneck for asynchronous operations. Too many async operations may cause the application to behave erratically.
  • Some features are not yet supported in WASM builds (ex: helpers, tools etc). Create a feature request if you want to see a specific feature in WASM builds (and see the error in the console for a missing feature).

Build options

When building wasm applications there are multiple fields that can be set. Note that the initial values can be left as is, none of the fields need adjusting to create a build. Some fields just set default values to the application and can be overwritten by url parameters on open time.

Name Description Can be altered with url parameter or post build session alteration
Version addition Adds a unique suffix next to application build version. {version}-{version addition} No. Used on build time only.
Client code Adds a default client code to the build. Used when the link does not contain any client codes. Only use if the build is meant for a specific client otherwise leave empty. Yes. Should be passed when opening the application.
Select JS serve method Changes the way JS is being served from the wasm application.
- Blob will compile all js to a single blob and serve it on startup.
- Per template works like the server and js files are served as marked on template.		 No. Used on build time only.
Select WASM api mode Defaults to live.
Offline is currently depracated as this mode directs all calls to the old offline ms.
app_users is also deprecated as its replaced by app_users_v2.
app_users_v2 when the application is using app users in b2b mode.		 Yes. The mode can be changed at any time of the application. Leave empty for default live (regular bo users)
Select WASM cart mode Switch cart mode to either the inv docs api or the internally built version. Only needed if the application actually uses cart functionality. Default is server where all inv docs cart calls contact the server. Internal will use the built in version instead. Yes. This mode can be changed at any time of the application. Leave empty for live.
Use internal cart backup Only shown and used when cart mode is internal. When selected then wasm will backup the cart to kvs and reload it when it starts. Yes. This mode can be changed at any time of the application.
Additional applications With this we can add extra applications (module v2 or even full applications) to the same wasm build. This is the way to make V2 modules available to the build, use the checkbox to set the module to enabled/disabled on application load. No. Used on build time only.

Note that if we set default modes here during build time, then we do not need to select these values with the open link.

Builder updates

Check the changelog area for the information on major updates. Changelog

Subsections of WASM builds

Builder changelog

This page contains the changelog for the builder. It is updated with each new release of the builder.

1.54.5

  • GS-25581 Updated targeted loads on services. Same page targets will no longer force the full re-render. Extended functionality to forms with actions.
  • GS-26908 Fixed a load order issue in dev builds that was overwriting data of templates when it was loaded in a specific order

1.54.4

  • App user model in session now includees the loginMethod field. The session will also include the app accesses and warehouse accesses in the session. This is also filled when using app user with the back office auth driver.
  • GS-25581 Service builds: a nodes with targeted loads will no longer skip the main navigation
  • GS-25581 Service builds: data passes from the targeted loads from functions will now work similar to wasm
  • GS-26708 Dev builds: Configuration is now validated before it get loaded
  • GS-26708 Dev builds: Improved load and reload operation to be more lightweight
  • GS-26871 Added stale write guard for targeted loads elements to prevent old calls that might take time to complete from overwriting newer calls that already updated the content

1.54.3

  • Adjusted .Tools.GetMenuStructure to return the same level data as on the server

1.54.1 / 1.54.2

  • GS-26476 Adds support for InventoryApi dynamic api integration
  • GS-26490 CallTemplate calls will no longer append the ? character to the url without the query parameters or when the path input already contains one
  • GS-26490 The autofocus functionality of the server can now be mimicked by adding the attribute data-wsm-refocus on the body node of the current page
  • Added ApiCommandBroker to supported internal dynamic api’s
  • GS-25581 Improved service build targeted loads functionality so it supports detached forms from buttons

1.54.0

  • Local development build related updates

1.53.1, 1.53.2

  • Fixed an issue where template matching logic was case-sensitive from the default template link, causing it to fail on index as the index is always lower case
  • Various maintenance updates

1.53.0

  • GS-26283 Updated dataLoad to make automatic object to gjson conversions (imorted from server behaviour)
  • GS-26283 Added FDR api integration to wasm
  • GS-26283 Adds support for .Data.Files
  • Added automatic menu structure translation to service/wasm builds
  • GS-26284 Adds new optional 4th parameter to target load from functions .Tools.AddLoadTarget "wtl-table-b-page" "#table-b" "afterx" (mkMap "key" "val"). Contents are readable on that page from .Data.Parameters
  • Improved targeted load script for service builds, it will now also parse load parameters from form elements

1.52.2

  • Configuration update. No functional changes.

1.52.1

  • Fixed an issue where script tags would be purged of extra attribute tags and its type always adjusted to text/javascript

1.51.0 and 1.52.0

  • GS-25717 Service and app routes now support app routes navigation. It also supports navigation by template route alone if the app route is not provided.
  • GS-25581 Adds targeted loads fallback capability to service builds, so application builds would not lose functionality when built there. This is currently experimental and will likely receive further changes for its behaviour.
  • Adds helpers to be available dtSince and indexOfStringSlice
  • Adds tools helper to be available {{ .Tools.GetStaticNavPath "my-page" }}
  • GS-25845 Adjusted toTitle behaviour to match that of the server
  • Added new tools helper to list all applications and v2 modules that have been added to the build {{ .Tools.ListV2Modules }}
  • Build flow improvements: fixed an issue where the new flow would reach command line length limits on large applications.
  • GS-25834 Adds new tools helpers (for use in functions only) for B2B authentication (B2BLogin, B2BLogout, B2BLoginRegister, B2BRequestPasswordReset and B2BConfirmPasswordReset)
    • All take in the same json instruction as the corresponding calls on the api {{ .Tools.B2BLogin {“username”: “”, “password”: “”, “authDriver”: “password”} }}. The template field is filled automatically.
  • GS-25894 Adds new helpers to generate local bcrypt hashes and verify them {{ bcryptHash "my-password" }} and {{ bcryptVerify "my-password" "the-hash" }}
  • GS-25232 RunQueryV2 is now supported on service and wasm builds
  • Adds support for ApiLogFiles api in integrated dynamic API’s
  • GS-25602 Adds an option to render js scripts as per-template scripts (same as the server and service does) instead of the single blob. This is experimental and will likely break applications that have already been built with the default single blob setting.