Skip to main content

 

 

 

 

 

 

 

 
 
OutSystems

OutSystems Platform side effects and breaking changes

This document lists the side effects and breaking changes introduced in OutSystems® Platform 9.1 relative to release 9.

OutSystems is committed to minimize its customers’ effort when upgrading their installations to a new major release of OutSystems Platform.

As such, before introducing a breaking change for a new release, OutSystems carefully analyzes its impact, namely, the expected number of occurrences in its customers’ installations. A breaking change is introduced only if it affects a small number of customers.

Check Before You Upgrade

In version 9.0.1 the encryption algorithm that the OutSystems Platform uses to store the settings in the database was improved and applications in later versions of the OutSystems Platform are not able to read settings stored with the previous algorithm. To avoid downtime in Production environments, when upgrading OutSystems from a revision earlier than 9.0.1 you must do the following:

  1. Perform a full upgrade to the latest 9.0.1 revision;
  2. Validate the functionality of the applications running on OutSystems Platform 9.0.1;
  3. Perform a full upgrade to OutSystems Platform 9.1.

Breaking Changes

Security

  1.  

Issue: Passwords stored in ossys_User can no longer be compared using the Encrypt built-in function.

Stack: Both .NET and Java

Rationale: Until now, passwords were stored using the MD5 cryptographic hash function, which is considered an insecure algorithm. To make it more secure, SHA512 is used with a dynamic salt to generate password hashes. Passwords are automatically upgraded when users log into the Infrastructure Management Console, Environment Management Console, Development Environment, or to an application via the LoginPassword system action.

Workaround: Change logic with Encrypt to compare a user password against the password stored in the database. Use ValidatePassword instead (extension PlatformPasswordUtils).

  1.  

Issue: The viewstate is now encrypted. If your application or working methodologies require being able to read the viewstate contents, it will no longer be possible to do it. All postbacks must carry a valid viewstate.

Stack: Both .NET and Java

Rationale: Increase the resiliency of the applications to Cross-Site Request Forgery attacks.

Workaround: Turn off the viewstate encryption by changing a parameter in the database. Please contact Support for instructions on how to achieve this.

Java Extensions

  1.  

Issue: Extensions that compiled in Java 6 may not compile now in Java 8.

Stack: Java

Rationale: Java 8 introduces several changes that may generate errors when compiling extensions.

Workaround: Change the extension code, in the following scenarios:

  1. Deprecated APIs: Check Java documentation to identify the new APIs that replace the old ones. Change extension code to start using the new APIs.

Example: method Thread.stop(Throwable) was already deprecated for some time, and now was removed.

  1. Changed System Interfaces - When an extension extends or implements Java types changed, compilation errors may occur. This is because new members are not implemented and the extension must implement them. Name clashing errors may also occur and, in this case, members of derived types defined in the extension must be renamed.

Example: Interfaces of java.sql.Statement changed from Java 6 to Java 7 and there are no changes from Java7 to Java 8. Extensions implemented using these interfaces will not compile with Java SE 8.

For more details read Oracle compatibility documentation for Java 7 and Java 8.

  1.  

Issue: Some libraries shipped with the Platform were upgraded. Extensions referencing them may stop working.

Stack: Java

Rationale: Due to the upgrade of the Java runtime, some Platform libraries were upgraded.

Workaround: Check extensions referencing Platform libraries and change the code to use the new ones. A complete list of libraries can be obtained here:

$OUTSYSTEMS_HOME/lib

For example, library commons-pool.jar was upgraded and the package name changed from org.apache.commons.pool to org.apache.commons.pool2. Old code won't link with the new version.

Java Platform APIs

  1.  

Issue: Platform APIs now accept and return Lambdas instead of Actions.

Stack: Java

Rationale: Improve generated code readability and decrease computational overhead caused by anonymous classes.

Workaround: Take the following action to the code that is using Platform APIs:

  • Recompile the Code
    • When using an Action class as argument to a new API that expects a Lambda class;
    • When expecting a Lambda class but the old API returns an Action class.
  • Change the Code
    • When expecting an Action class but the new API returns a Lambda class:
      Old Code New Code

      Action0 action = ...;

      Action0_Lambda action = ...;

    • When overriding a class or interface member with a Lambda class in its signature, instead of an Action class:
      Old Code New Code

      void method(Action0 action)

      void method(Action0_Lambda action)

Aggregates

  1.  

Issue: Sum() and Count() built-in functions return Long Integer instead of Integer when used in aggregates. The upgrade might originate errors when the aggregate result is assigned to a structure.

Stack: Both .NET and Java

Rationale: With the support for Long Integer values in the Platform, aggregates now use Long Integer values when computing sums or counts.

Workaround: Go to the structure, select the attribute that holds the result of the sum or count, and change its data type to Long Integer.

Performance Monitoring

  1.  

Issue: LifetimeMonitoring API is deprecated.

Stack: Both .NET and Java

Rationale: The RequestData table is replaced by the new RequestEvent table, adding more comprehensive data collected from requests to the Platform.

Workaround: RequestData will keep all its data. Starting in Platform 9.1, data is obtained using the new RequestEvent REST API, which is exposed by PerformanceProbe module (in System Components).

Database Connections

  1.  

Issue: Database connections that use connectors developed using the Database Integration API stop working.

To verify if your database connections use such connectors, open the environment management console. Select ‘Administration’ and ‘Database Connections’. Check if there is any connection from a DBMS provider other than iDB2, MySQL, Oracle, or SQL Server.

Stack: Both .NET and Java

Rationale: Support for the Long Integer data type was added to the Database Integration API, and requires changes in the connector.

Workaround: Contact the developer of the connector to obtain a compatible version. Alternatively, if you have access to the connector’s source code, enroll in the Database Integration API limited availability program to make the necessary changes yourself.

Database Catalogs

  1.  

Issue: It is not possible to create or change catalog configurations in Service Center that have a collation different from the Platform main catalog.

Stack: Both .NET and Java.

Rationale: OutSystems Platform does not support catalogs with different collations.

Workaround: None.

User Interface

  1.  

Issue: Feedback Messages from RichWidgets are rendered with HTML formatting by default, instead of encoding the HTML. This was the original behavior in P9 and was switched to "encoded by default" as a fix for a discovered security vulnerability, but is now being reverted to the original behavior.

Stack: Both .NET and Java.

Rationale: The contents of the Feedback Message are being sanitized by OutSystems Platform automatically, so there is no longer a security issue that requires such contents to be encoded. Now the Feedback Message can actually be used the way it was meant to be used: with HTML formatting, not with HTML encoding.

Workaround: Force the encoding of the messages by changing the default value of the RichWidgets site property FeedBackMessage_ForceHTMLEncode to True.

SOAP Web Services

  1.  

Issue: In consumed SOAP web services, the conversion of unsignedLong is now done to Text, instead of Integer.

Stack: Both .NET and Java.

Rationale: An unsignedLong must be converted to Text or, otherwise, there's the risk of losing precision.

Workaround: Refresh your SOAP web services and change the logic of your application to fix the errors identified by True Change.

Side Effects

Security

  1.  

Issue: Extensions using (non-supported) methods Settings.Encrypt and Settings.Decrypt (of RuntimePlatform API), will stop working as expected.

Stack: Both .NET and Java

Rationale: Settings were stored using RC4 with fixed IV, which is considered an insecure hashing algorithm. To make settings secure, AES128 with a dynamic IV is used to encrypt settings.

Workaround: Review extensions to stop using Settings.Encrypt and Settings.Decrypt methods.

  1.  

Issue: Calls to (non-supported) Platform web services which require authentication will fail.

Stack: Both .NET and Java

Rationale: Due to security constraints, passwords stored with MD5 will be automatically upgraded to be stored using SHA512 with dynamic salt. Calls to non-supported Platform web services using Encrypt built-in function to generate the password hash will fail with invalid login.

Workaround: Review applications to stop using (non-supported) Platform web services.

  1.  

Issue: When doing a backup of the machine running the Platform server, include the private key. If not included, credentials will have to be re-entered for the various Platform configurations: External Database Connections, Multiple Database Catalogs, etc., and the environment will also need to be re-registered in the infrastructure management console.

Stack: Both .NET and Java

Rationale: Due to security constraints, sensible data stored in the database - like passwords - is now encrypted with a private key - automatically generated, but private to each environment. This private key is stored in the private.key file, far from the data.

Workaround: File private.key should be included in the backup, like the database configuration file (server.hsconf). Both files can be found in the Platform installation directory.

  1.  

Issue: Message text in Feedback Message (RichWidgets) is now escaped to make it more secure.

Stack: Both .NET and Java

Rationale: This security measure avoids the injection of code in the Feedback Message text.

Workaround: To have the new behavior in existing Feedback Messages, set the new property to escape content to True. All new Feedback Messages will have the new behavior by default.

Java Extensions

  1.  

Issue: Extensions that compiled in Java 6 may not compile now in Java 8.

Stack: Java

Rationale: Java 8 introduces several changes to the language that may generate errors while compiling extensions.

Workaround: The upgrade of Java runtime forced upgrading libraries shipped with the Platform. Some are intended for OutSystems use only. In case extensions are also using them, check those extensions.

Performance Monitoring

  1.  

Issue: In the infrastructure management console, the Performance dashboard is replaced with a new dashboard called Analytics, containing more information about requests to the Platform.

Stack: Both .NET and Java

Rationale: To provide with an overview about the end-user experience of your applications, and to give you the opportunity to drill down and understand the factors that influence it.

Workaround: All new data can be analyzed in the Analytics dashboard. As for the old data, it can be accessed through the old dashboard, which still works.

  1.  

Issue: When upgrading an environment with multiple front-ends, performanceprobe.js might generate 404 errors on the client JavaScript console when contacting PerformanceProbe REST API or Beacon web screen.

Stack: Both .NET and Java

Rationale: The previous collection method was replaced by a REST API method in PerformanceProbe. This allows developers to easily register their custom RequestEvents in a more standard way. The endpoint to where performanceprobe.js reports the collected data was changed. The web screen working as beacon was removed.

Workaround: Follow a balanced upgrade approach, to minimize having simultaneous front-ends available with different Platform versions. The worst-case scenario is to lose some metrics of client-side execution. This issue disappears after upgrading all front-ends and republishing all applications.

Platform Logs

  1.  

Issue: In release 9.1, a new logging table was added to store data about request events. This may cause the database to grow. Logs about incoming web requests occupy approximately 2.5 times more space than before.

Stack: Both .NET and Java

Rationale: Store more information about requests to allow richer analytics.

Workaround: After the upgrade, monitor the database usage to understand the database growth.

  1.  

Issue: Added RequestKey, Entrypoint_Name, and Action_Name attributes to Platform logs.

Stack: Both .NET and Java

Rationale: RequestKey was added to General, Error, Screen, Integration, Extension, and Timer logs. This attribute is used to correlate these logs with data in the new RequestEvent table.

Entrypoint_Name was added to the General and Error logs. If filled, this attribute contains the entry point that is handling the request, e.g., a Web Screen.

Action_Name was added to the General and Error logs. If filled, this attribute contains the action that is handling the request, e.g., the Preparation action.

Workaround: Take into account the presence of the new attributes in queries to these log tables.

Notifications

  1.  

Issue: The action NotifyWidget was deprecated and renamed to NotifyWidget_Deprecated.

Stack: Both .NET and Java

Rationale: The OnNotify handler is executed synchronously in the same request and same transaction. To improve performance a new notification action is now provided. The old action is kept for compatibility.

Workaround: -

  1.  

Issue: OsNotifyWidget JavaScript function is now called OsNotify.

Stack: Both .NET and Java

Rationale: Make the API easier to use.

Workaround: The old function still exists for compatibility reasons. Change applications to use the new function.

Built-in Functions

  1.  

Issue: The Encrypt built-in function was moved.

Stack: Both .NET and Java

Rationale: Improvements to encryption lead to moving the Encrypt built-in-function to a new extension called PlatformPasswordUtils, in System Components.

Workaround: Republish modules to automatically start using Encrypt from the extension.

  1.  

Issue: Built-in functions TextToEntityRefText, IntegerToEntityRefInteger, EntityRefIntegerToInteger, and EntityRefTextToText were renamed to TextToIdentifier, IntegerToIdentifier, IdentifierToInteger, and IdentifierToText, respectively.

Stack: Both .NET and Java

Rationale: Due to the new support to Long Integers, the Platform required new built-in functions to convert to and from this new data type. These functions would have complex names considering the old naming convention. Therefore, we chose shorter names that are easier to understand.

Workaround: After the upgrade, new built-in functions replace old ones with no impact.

RichWidgets

  1.  

Issue: FontAwsome library was updated to version 4.3.0 in RichWidgets.

Stack: Both .NET and Java

Rationale: There are new icons in RichWidgets.

Workaround: To use the new icons, refresh the reference to RichWidgets.

  • Was this article helpful?