MindAccess Developer Plan Subscribers and MindAccess Operator Plan Subscribers

What's new

• Trend Prediction Service update with new features:

  • Model storage is changed

  • User can use Model Management API to check the model

What's new

• Update the Cloud Foundry to new version: v1.17 with security fix.

• New price is applied for Backing Service XS and Backing Service M plan.

• The migration solution guide for legacy MongoDB backing service on Alibaba cloud is published online.

Known issues

• Applications using the Mendix buildpack are currently not supported for MindAccess Operator

• When deploying an application to MindSphere, the app name has to be compliant with the MindSphere naming conventions.

• Binary File Storage: MindSphere does not currently have a compatible file service available to its Cloud Foundry stack. Therefore, you cannot use any Mendix features which rely on having a file service.

• At present, MindSphere only supports two roles. This should be taken into account when designing security within your Mendix app.

• It is recommended that you create two scopes for your MindSphere app, user and admin which will map to identically-named user roles in your Mendix app.

Known issues

• For security reasons a strict timeout is enforced. Currently this leads to the situation that the size of a file which can be uploaded/ downloaded depends on the network bandwidth at client side.

• When uploading files to the File Service, a file name must not contain blank spaces. Blank spaces in the file name will prevent the file form being stored.

• After deleting an asset, associated files might still be accessible for up to 30 minutes as this data is deleted asynchrounously.

• Multi-part uploading or completing may failed with “500 Internal Server Error”. To avoid such failure, please make sure some interval (e.g 3s, must be greater than 1s) between each part uploading request or before completing the multi-part uploading.

What's new

• Standard Deviation is now available for Bulk Service

Known issues

• The maximum payload size of a message sent to time series service as part of a PUT request cannot exceed 1 MB.

• The service will never return more than 2000 records in a response

• After deleting an asset, respective Time Series data might still be accessible for up to 30 minutes as this data is deleted asynchronously.

• When creating or updating an aspect it might take up to 30 minutes until aggregated data can be read for this aspect. Writing data or reading raw data is possible immediately.

• When getting the job status of a bulk import job, the response might not always contain detailed information on errors that occurred.

• When using “select” parameter in GET method of Time Series API, the response might not always contain all the data in the below scenario:

There are 3002 time series data in the given time range of GET method, the earliest time values "_time1" and the latest value is "_time3002". There are only 3 "var2" as in below table. When "var2" is considered by “select” parameter, only "var2" from "_time1" would be returned.