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 relatively to release 8.

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

  1.  

When upgrading your OutSystems Platform from 6.0 or earlier, you must upgrade to the latest revision of OutSystems Platform 8.0, and only then upgrade to P9. This is required for each environment on the infrastructure.

However, application modules (eSpaces and extensions) can be upgraded directly to P9, by opening them on the P9 development environment.

  1.  

If BPT is being used in the applications, it’s only possible to upgrade to release 9 without downtime, if you have a revision that supports this:

  • Upgrading from 7.0: revision 7.0.1.25 or higher must be installed;
  • Upgrading from 8.0: revision 8.0.1.8 or higher must be installed.
  1.  

When upgrading to OutSystems Platform 9, some database connections may not be upgraded automatically. Before making any changes to the database, the Configuration Tool lists all the connections that cannot be automatically upgraded. Change the listed connections in Service Center to ensure that they can be automatically upgraded. For more information, please refer to http://www.outsystems.com/goto/upgrade-db-connections.

  1.  

After upgrading OutSystems Platform to release 9, the application modules need to be upgraded. To do this, either create a solution with all your applications and publish that solution, or open each application in Service Studio.
To upgrade your applications using Service Studio, you need to be connected to an environment, so that OutSystems Platform can retrieve runtime information about the application. This environment must have the same configurations as the environment where the applications will run – same database provider, same external connections, and same date format.

Breaking Changes

.NET Framework

When upgrading to OutSystems Platform 9, applications are upgraded to use .NET 4.5.1. This upgrade is automatic, but since there are breaking changes introduced by the .NET Framework, it can affect custom configurations, extensions, or external libraries.

This section contains the .NET 4.5.1 breaking changes that might affect OutSystems applications. You can find the complete list of .NET 4.5.1 breaking changes in the Microsoft documentation like.NET 4 Migration Issues and ASP.NET 4 Breaking Changes.

  1.  

Issue: Non-OutSystems applications that are not compatible with .NET 4.0 and running under the OutSystemsApplication application pool, might stop working after the upgrade.

Stack: .NET

Rationale: In release 9 the OutSystemsApplication application pool was upgraded to use .NET 4.0.

Workaround: Move all non-OutSystems applications from the OutSystemsApplication pool to an application pool using .NET 2.0.

  1.  

Issue: Application pools other than the ‘OutSystemsApplication’ are upgraded to .NET 4.0 if they only have OutSystems Applications. Application pools that have both OutSystems and non-OutSystems applications are not upgraded, which may cause OutSystems applications to stop working.

Stack: .NET

Rationale: Automatically upgrading application pools with non-OutSystems applications to .NET 4.0 could make them to stop working.

Workaround: Move all OutSystems applications to application pools with .NET 4.0.

  1.  

Issue: After the upgrade, the .NET Framework 4.0 machine.config will be created with the default settings. All customizations made to the .NET Framework 2.0 machine.config file, need to be reapplied to the machine.config file of .NET Framework 4.0.

Stack: .NET

Rationale: When upgrading to .NET 4.0, a new machine.config file is created.

Workaround: Check all customizations done to the machine.config files for both 32 and 64 bit versions of .NET 2.0, and apply them to the .NET 4.0 files. Be sure to replicate all changes done under the “appSettings” element and in “requestTimeout” and “maxRequestLength” attributes of the “httpRuntime” element.

The .NET machine.config file can be found at:

%windir%\Microsoft.NET\<architecture>\<framework version>\CONFIG\machine.config

  1.  

Issue: Extensions and external libraries using unmanaged code where the managed code performs incorrect calls to the unmanaged APIs, may cause the application to stop working.

Stack: .NET

Rationale:Previous versions of the .NET Framework were handling this error. To improve performance, the errors are no longer handled by .NET Framework 4.0, so now the incorrect calls might crash.

Workaround: Unmanaged code calls can be identified by searching the code for DllImport usages.

To help you troubleshoot applications that are crashing due to this issue:

  • Add the legacyCorruptedStateExceptionsPolicy setting to the C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Aspnet.config file:
<configuration>
  <runtime>
    <legacyCorruptedStateExceptionsPolicy enabled="true"/>
  </runtime>
</configuration>
  • After saving the changes to the Aspnet.config file, restart the IIS and replicate the problem;
  • Check the error logs in Service Center and use the error information to detect which extension action is causing the problem;
  • Change the extension action to fix the problem;
  • Once all problems are fixed, remove the legacyCorruptedStateExceptionsPolicy setting, and restart IIS.

Notice that this does not fix the problem, it only allows the error to be logged in Service Center, helping you find the source of the problem. If you have problems troubleshooting this issue, contact OutSystems Support for assistance.

  1.  

Issue: In application pools running in 32 bits, extensions and external libraries using unmanaged code that is invoked with incorrect calling conventions can cause the application to stop working.

Stack: .NET

Rationale: Previous versions of the .NET Framework were handling this error. To improve performance, the errors are no longer handled by .NET Framework 4.0, so now the incorrect calls might crash.

Workaround: If the applications can run in 64bits and the operating system is 64bits, change the Application Pool of the application to 64 bits. Set the “Enable 32-Bit Applications” setting to False in the Application Pool advanced settings.

If changing the pool settings is not an option, check the breaking change 0for instructions on how to find the source of the problem.

Resources Deployment

  1.  

Issue: Applications are no longer able to deploy resources to outside its virtual directory.

Stack: Both .NET and Java.

Rationale: Enhance security.

Workaround: Change the ‘Target Directory’ of the resource to deploy it inside the module’s virtual directory.

Database Connections

  1.  

Issue: When upgrading to release 9, some database connections may not be upgraded.

Stack: Both .NET and Java.

Rationale: For release 9 the database connections were changed to provide support for new database providers such as DB2 and MySQL.

Workaround: When using the Configuration Tool to perform the upgrade, before any changes are made to the database, the Configuration Tool checks all database connections, and lists all the connections that cannot be automatically upgraded.

In Service Center, change each of those connections to ensure the connection is created by Service Center, and not by manipulating HTML and JavaScript. For more information, please refer to http://www.outsystems.com/goto/upgrade-db-connections.

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.

New .NET/Oracle Driver

  1.  

Issue: Oracle queries now have timeouts.

Stack: .NET using an Oracle database.

Rationale: The Oracle drivers were replaced.

Workaround: Increase the default query timeout setting in the Configuration Tool.

Issue: Driver configurations performed directly in the Windows registry, tnsnames.ora, or sqlnet.ora might not work after the upgrade.

Stack: .NET using an Oracle database.

Rationale: The Oracle drivers were replaced.

Workaround: Review all custom configurations placed in either in the Windows registry, tnsnames.ora, or sqlnet.ora and ensure that they work with the Oracle ODP.NET Managed Driver. See the ODP.NET documentation to learn more.

Issue: Driver connection string attributes defined in the Advanced Settings window in the OutSystems Configuration Tool, which are specific to the ADO.NET OracleClient driver, might not work after the upgrade.

Stack: .NET using an Oracle database.

Rationale: The Oracle drivers were replaced.

Workaround: Review all connection string attributes placed in the Advanced Settings window, either in Database and Session tabs in Configuration Tool, and ensure that they work with the new ODP.NET Managed Driver. Check Oracle’s documentation to learn about the supported connection string attributes.

  1.  

Issue: When upgrading to OutSystems Platform 9, Oracle databases with the CURSOR_SHARING configuration parameter set to ‘SIMILAR’ or ‘FORCE’ cause the upgrade to fail. This is a known issue with the Oracle driver.
Stack: .NET using an Oracle Database.

Rationale: The Oracle drivers were replaced.

Workaround: Set the CURSOR_SHARING parameter to "EXACT", and follow the OutSystems Platform installation checklist.

Simple Queries

  1.  

Issue: Simple Queries are automatically converted into Aggregates. Input parameters that are not used in the query, will not be added to the Aggregate filter. If you are relying on input parameters to invalidate the query cache, it will no longer work.

Stack: Both .NET and Java.

Rationale: Unlike Simple Queries, Aggregates have access to the entire scope in which they are used.

Workaround: For each unused input parameter a reminder is added to your application. To keep using the parameter, create a dummy filter (e.g. parameter1 = parameter1).

Web Services

  1.  

Issue: Web Reference methods with a timeout set to 0 seconds are changed to have a timeout of 3600 seconds (1 hour).

Stack: Both .NET and Java.

Rationale: Make the .NET and Java stacks consistent.

Workaround: Set a valid timeout value. If you are relying in the 0 seconds timeout to have an infinite timeout, then replace the value with one that is big enough to fit your needs.

  1.  

Issue: The ‘Log Requests’ property was removed from consumed Web Service methods. Additionally, the ‘Log_requests’ attribute was removed from the Web Reference system entity.

Stack: Both .NET and Java.

Rationale: Logging is important for Web Service troubleshooting and performance analysis, so it’s always turned on.

Workaround: If you want a specific Web Service method not to be logged, isolate it in a separate module and disable logging for that module in the environment management console.

If you have modules that use the ‘Log_requests’ attribute of the Web Referencesystem entity, you will need to change them to remove the references on this attribute.

  1.  

Issue: Record and Record List type names now have a "Record" or "RecordList" suffix appended. Since the full type name can be up to 130 characters long, the name (before adding the suffix) can get truncated.
Record List type names are used in each XML payload of SOAP web services exposed by OutSystems. Previously existing consumers of these web services (both OutSystems consumers and external ones) will get empty structures for the types with the previous name without the suffix.
There's no impact in Record type names, since they are only present in the WSDL and not in the actual web service XML payload.

Stack: Both .NET and Java.

Rationale: Naming convention.

Workaround: Update any references pointing to the exposed web services containing Record List type names with more than 130 characters. For OutSystems web service consumers, right-click on the SOAP web service consumer and select "Refresh SOAP Web Service...".

Extensions

  1.  

Issue: Extensions without source code are not upgraded.

Rationale: Support generic lists.

Stack: Both .NET and Java.

Workaround: Get the source code, include it in the extension. Verify the extension to see if it compiles, and save it.

  1.  

Issue: The record, structure, and record list classes have changed. Extensions using these classes might no longer compile.

Rationale: Support generic lists.

Stack: Both .NET and Java.

  1.  

Issue: The RecordList is no longer an abstract class but an interface. Some methods are no longer available.

Stack: Both .NET and Java.

Rationale: Start supporting generic lists.

Workaround: Only extensions using reflection need to use the RecordList interface. In this situation, implement the functionality using the methods available in the RecordList interface.

Runtime APIs Used in Extensions

  1.  

Issue: The logic to access the database was changed in the RuntimePlatform library. All Extensions using these classes might stop working.

Stack: Both .NET and Java.

Rationale: All logic to access the database was centralized and simplified, making it independent of the database provider. All this logic is now centralized in the RuntimePublic.Db library.

Workaround: Check all Extensions that access the database, and see if they compile after the upgrade.Replicate the same logic using the RuntimePublic.Db.

  1.  

Issue: The ProcessDeletion.DeleteProcesses() method of the RuntimePublic library no longer receives a transaction as parameter. Extensions using this method will stop working.

Stack: Both .NET and Java.

Rationale: With the changes to access the database, it’s no longer needed to pass a transaction to delete a process.

Workaround: Remove the parameter from the method calls.

  1.  

Issue: Extensions that used the Oracle driver libraries directly, may stop working.

Stack: .NET or Java stack using an Oracle database.

Rationale: The Oracle drivers were replaced.

Workaround: Change the extension to start using the DatabaseAbstraction library.

  1.  

Issue: When executing stored procedures in extensions, if the stored procedure command has the CommandType set to Text, then the statement must be inside a BEGIN…END; block or it will stop working.

Stack: .NET stack using an Oracle database.

Rationale:The Oracle drivers were replaced.

Workaround: use "call proc(in, out)" => "begin proc(in, out); end;"

Logs

  1.  

Issue: The Log_Error and Log_Error_Previous entities are now read-only. From 9.0 onwards, applications are no longer able to create, update or delete records in these entities.

Stack: Both .NET and Java.

Rationale: These are internal entities for logging purposes.

Workaround: Create a custom entity to log the information.

  1.  

Issue: Starting in version 9.0.1.3, the Log_Web_Service and Log_Web_Reference entities are deprecated and are kept for backward compatibility only. The logs are stored in the Log_Integration entity.

Stack: Both .NET and Java.

Rationale: Store logging information of all types of integrations in a single entity.

Workaround: To access the logged information, replace all usages of the Log_Web_Service and Log_Web_Reference entities by the Log_Integration entity, and filter by the Type attribute with values "SOAP (Expose)" and "SOAP (Consume)".

  1.  

Issue: Starting in version 9.0.1.3, the Name attribute of theLog_Web_Service entity is empty.It is kept for backward compatibility.

The Name value of the logs is available in the Log_Web_Service entity, at the beginning of the Method attribute.

The same value is available in the Log_Integration entity as well, at the beginning of the Action attribute.

Stack: Both .NET and Java.

Rationale: Standardize attributes used in the new Log_Integration entity.

Workaround: Access the Action attribute of the Log_Integrationto extract the name of the exposed web service.

Side Effects

  1.  

Issue: The environment management console no longer has the functionality to create scripts to move the application data between catalogs/schemas.

Stack: Both .NET and Java.

Rationale: Since the OutSystems Platform is database agnostic, this functionality is no longer available.

Workaround: Create the database scripts manually.

  1.  

Issue: When converting Simple Queries to Aggregates, comparisons involving Date, Time, and Date Time types are now made using explicit conversions functions. The upgrade process automatically detects these situations and changes the source code if needed. There is no need for manual intervention, the behavior of your queries will remain unchanged.

Stack: Both .NET and Java

Rationale: Make Date, Time, and DateTime implicit conversions behavior consistent between server logic and database logic.

Workaround: None.

  1.  

Issue: In release 9, new logging tables were added to store the full stack trace of errors. This may cause the database to grow.

Stack: SQL Server, Oracle

Rationale: Store more information about an error to allow support and maintenance teams to troubleshoot it.

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

  1.  

Issue: In version 9.0.0.23, ECT has an improved configuration mechanism with a new back office and is now called App Feedback:

  • User feedback is enabled/disabled per application instead of module;
  • User feedback is enabled/disabled for groups of users.

Stack: All.

Rationale: Make it easier to configure user feedback by tying it in with user management (Users application).

Workaround: Open the new back office and validate that the groups created in the upgrade are enabling feedback for the right users in the right applications.

  1.  

Issue: Starting in version 9.0.1.3, when deploying applications in the infrastructure management console, you cannot downgrade errors about broken dependencies to warnings.

Stack: Both .NET and Java

Rationale: Ensure full consistency of your infrastructure, by not allowing to publish applications with broken dependencies.

Workaround: It’s still possible to publish modules with broken dependencies in the environment management console.

  1.  

Issue: Starting in version 9.0.1.3, methods in LifeTime Service API (SOAP) include an additional output parameter called "Success”, which is true when the method execution is successful, false otherwise.

Stack: Both .NET and Java

Rationale: Make it easier for developers to understand if the method execution ended successfully or not.

Workaround: If you are consuming this API in your OutSystems applications, refresh the dependency in order to update methods with the new parameter.

If you are consuming this API via a standalone application, you may or may not need to refresh your code, depending on the way you generate the stubs.

  1.  

Issue: Starting in version 9.0.1.3, the Report_Line entity has a new attribute called “ReportType”. Hence modules using it have an outdated dependency on it.

Stack: Both .NET and Java

Rationale: New attribute to filter the type of integration report.

Workaround: In the development environment, refresh dependencies in modules using the Report_Line entity. Since this change is about an added attribute, there is no impact on applications because they are not using it.

  1.  

Issue: After the upgrade process to 9.0.1.3 or higher, the environment management console will use the new Log_Integration entity to display logs. As a result, the most recent logs created before the time of the upgrade aren’t visible. The time interval that is not covered by logs depends on the Log Cycle Period setting of your environment.

Stack: Both .NET and Java

Rationale: The integration logs now use new entities.

Workaround: To access the last logs written before the upgrade process that are not visible in the environment management console, query the oslog_Web_Service_* and oslog_Web_Reference_* tables directly in your Database.

Themes and UI Widgets

  1.  

Issue: Using functionality from the OutSystems Now application together with customized versions of the RichWidgets Input_Calendar Web Block, might cause your application to misbehave. This is due to both modules declaring a variable named “Calendar”.

Stack: Both .NET and Java

Rationale: The RichWidget calendar javascript was updated to ensure this conflict doesn’t happen. This behavior only happens in customized versions of the calendar widget.

Workaround: Update any custom Calendar widget by renaming the global “Calendar” variable.

  1.  

Issue: Starting in version 9.0.1.3, the look and feel of Charts components is slightly different. The HighCharts library was updated to version 4.1.4 with different captions, labels and new effects on mouse hover. Check the HighCharts Changelog for further information.

Stack: Both .NET and Java

Rationale: Updated the HighCharts library from version 3.0.9 to 4.1.4.

Workaround: None.

Permission Levels

  1.  

Issue: In the OutSystems Cloud, the Administrator permission level is no longer allowed to manage environments, front-ends and zones, and perform runtime configurations to system components modules.

Stack: Both .NET and Java

Rationale: Make the permission levels adequate to their use in software factories.

Workaround: None.

  1.  

Issue: Starting in version 9.0.1.3, permission level “Open & Reuse” in the infrastructure management console was renamed to “Reuse & Monitor”.

If you are upgrading an installation from a platform version prior to 8.0.1.23, any user with this permission level will now have access to the Analytics, Process Monitoring and Environment Health sections in the environment management console. Users with that level of privilege will also be able to Reference External Entities.

If you are upgrading from a platform version 8.0.1.23 or higher, the only change is the name of the permission level. Users with that level of privilege will also be able to Reference External Entities.

Stack: Both .NET and Java

Rationale: This permission level allows developers to open and debug applications, reuse application elements, monitor applications and their processes.

Workaround: None.

  1.  

Issue: When upgrading to version 9.0.1.3 or higher, application-specific permissions defined in the infrastructure management console are migrated to roles with the same security levels. These new roles are granted to users in order to keep the security scenario prior to the upgrade. For further details, please see this forum post.

Stack: Both .NET and Java

Rationale: Upgrade of the old permission model to the new one.

Workaround: None.

  1.  

Issue: Starting in version 9.0.1.3, the minimum permission level for adding a new or using an existing external entity in an extension is:

  • “Reuse & Monitor” the infrastructure management console, or
  • “Download” in the environment management console.

To publish modules that have dependencies on external entities, users need the following permission:

  • “Change & Deploy” in the infrastructure management console, or
  • “Publish” in the environment management console.

If the external entity is owned by another application, or there is already a module depending on it, then you will need to have at least “Reuse & Monitor” for that application or module.

Stack: Both .NET and Java

Rationale: Enforcing the security for these operations, as external entities may contain sensitive information.

Workaround: None.

  • Was this article helpful?