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

OutSystems is committed to minimize its customers’ effort when upgrading their installations to a new major release of the 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.  

To avoid downtime in the Production environment when upgrading to version 8, from versions 6.0 or 7.0, it is required that you have already installed a revision that is prepared for the effect:

Upgrading from 7.0: revision 7.0.0.7 or higher must be installed;

Upgrading from 6.0: revision 6.0.1.19 or higher must be installed.

  1.  

Issue: If any of LifeTime's eSpaces or extensions are deployed on another catalog/schema, LifeTime will stop working properly after the upgrade.

Stack: Both .NET and Java.

Rationale:  All System Components should be deployed on the main database catalog/schema.

Workaround: Ensure that before upgrading, all LifeTime eSpaces and extensions are deployed in the main database catalog/schema.

  1.  

After upgrading to the OutSystems Platform 8, LifeTime's new performance monitoring capabilities become available. Due to this, LifeTime automatically starts collecting and storing client-side metrics.

For each client request, metrics are collected and stored in the Production environment for a period of 48 hours. To estimate the maximum storage needed for metrics in Production, calculate it as follows:

MaximumStorageNeededForProduction = AveragePageViewsPerDay * 2 days * 1100 Bytes.

As an example, imagine an environment that has 1 million page views in 2 days (distributed between all the applications), the database size will increase approximately 2.05GB.

Lifetime copies periodically the collected metrics from Production to its own database (either if Lifetime is installed in Production or any other different environment) and also keeps it for a period of 48 hours. However, Lifetime does an aggregation of collected metrics and stores it permanently per day. To estimate the storage needed for Lifetime’s database, calculate it as follows:

  • A fixed storage size equal to what was calculated for Production;
  • Add a constant daily growth due to the aggregated metrics:

AverageLifeTimeDBDailyGrowth = AveragePageViewsPerDay * 100Bytes

In the example above, this would mean that the Production database would start by having 2.05GB, and increase 95 MB daily.

Furthermore, if you have the database set to use full-recovery model (SQL Server) or Archivelog (Oracle), the transaction log will increase with each Insert and Delete operation performed by LifeTime Performance Monitoring.

To estimate the growth of the transaction log, you can calculate it as follows:

TransactionLogsAvgDailyGrowth = AvgDailyPageViews * AvgRecordSize * 3

In the example above, this would mean that the Production database would grow by 3.3GB per day, and the same would happen to the LifeTime database.

Breaking Changes

Widgets, CSS, and JavaScript

  1.  

Issue:  Factories that customized the RichWidgets eSpace will no longer be able to keep those changes in version 8.

Stack: Both .NET and Java.

Rationale: To make the OutSystems Platform upgrade simpler in future versions, from version 8 onwards, the RichWidgets eSpace is a read-only eSpace.

Workaround: Create a new eSpace with the customized widgets, and change all consumer eSpaces of the customized widgets to start using the new eSpace instead of the RichWidgets.

  1.  

Issue: Some widgets like the Input_Calendar and Feedback_Message will be displayed differently to end-users.

Stack: Both .NET and Java.

Rationale: To improve the look and feel of widgets, small changes were introduced to the CSS styles of RichWidgets.

Workaround: To revert this change, simply override the widgets styles in your application theme. You can use previous versions of RichWidgets as a reference

  1.  

​​Issue: Edit Records that were being successfully validated on the server-side might now be unsuccessful.

In previous versions of the OutSystems Platform, when an input widget was associated with an Edit Record through its 'Parent Edit Record' property, if the input was placed inside a Table Record or List Record, it would be disregarded when computing the Edit Record's 'Valid' property during server-side validations.

From the current version of the OutSystems Platform onwards, all inputs associated with an Edit Record through the 'Parent Edit Record' property, are taken into account when computing the 'Valid' property of the Edit Record, independently of where the input widget is located within the Web Screen.

Stack: Both .NET and Java.

Rationale: Make the widgets behavior consistent: a widget that is not rendered should not be considered in the parent Edit Record validation.

Workaround: Check input widgets that are used inside Table Records and List Records, and have the 'Parent Edit Record' property set. Review the server-side validations, taking into account that these input widgets now contribute to the Edit Record 'Valid' property.

  1.  

Issue: The prompt property was changed: if the browser supports the placeholder attribute for input elements, then the prompt text is set into the placeholder attribute of the generated HTML, otherwise the prompt text is set into the value attribute of the generated HTML, just like in previous versions of the OutSystems Platform.

Javascript relying on the ‘prompt’ attribute of the generated HTML being set as the value attribute of input elements may fail.

Stack: Both .NET and Java.

Rationale: To make the OutSystems Platform compliant with web standards.

Workaround: Change the scripts to use the placeholder attribute instead of the value attribute.

  1.  

Issue: All applications with custom Ajax animations will stop performing the animation.

In previous versions of the OutSystems Platform it was possible to use custom Ajax animations. In the OutSystems Platform 8 this is no longer supported.

Stack: Both .NET and Java.

Rationale: The internal JavaScript libraries used by the OutSystems Platform were changed.

Workaround: Check if your applications manipulate the OSOnBeforeChange or OSOnAfterChange Javascript variables, and change the Ajax Refresh to use one of the animations provided.

  1.  

​​Issue: Tables, Table Records, Show Records, and Edit Records that have an extended property for the 'class' attribute will be displayed as inline elements instead of block elements. If widgets near Tables, Table Records, Show Records, and Edit Records are also inline elements, these elements might flow to fill-in the space left, making the screen render differently to end-users.

This issue impacts very few applications, since for it to happen it is necessary that the three combinations explained above occur simultaneously.

Stack: Both .NET and Java.

Rationale: To implement the new grid system, CSS classes are automatically added to widgets.

Workaround: Enclose Tables, Table Records, Show Records that have an extended property for the 'class' attribute in a container, and set the width of the container to 'fill-parent'.

Internet Explorer 7

  1.  

Issue:  Internet Explorer will no longer fallback to IE7 compatibility mode when accessing OutSystems applications on intranets.  End-users with Internet Explorer 8 or higher, might have issues if there was any old custom incompatible CSS or Javascript code developed specifically for IE7.

Stack: Both .NET and Java.

Rationale: Some of the new features of OutSystems Platform 8 require CSS level 2 support.

Workaround:  To test your applications, use ‘Compatibility View Settings’ (Alt+T) on Internet Explorer. To overcome this, you can either configure Internet Explorer to not use compatibility mode on intranets, fix any CSS or Javascript errors, or contact OutSystems Support.

ECT

  1.  

Issue: eSpaces referencing the GenerateGUID action from the ECT_PageRetriever eSpace will be left with broken references.

Stack: Both .NET and Java.

Rationale: The GenerateGUID action is no longer made available in the ECT_PageRetriever extension, because a new built-in function was created for this purpose

Workaround: .To fix this problem simply use the new System action GenerateGuid().

BPT

  1.  

Issue: The GetActivityCount, GetActivities, GetNewOpenActivity, SetSessionUserId actions and the Activity, and PaginationInfo structures were moved from the BPT_API extension to the new EPA_TaskBoxExtension. eSpaces referencing these actions or structures will be left with broken references.

Stack: Both .NET and Java.

Rationale: To provide a clear separation between the BPT and TaskBox APIs.

Workaround: To fix this, refresh the missing references and add new references to the EPA_TaskboxExtension actions and structures.

  1.  

Issue: The API_GetActivities and API_GetActivityPagination actions from the EPA_Taskbox eSpace were changed. eSpaces referencing these actions will be left with broken references.

Stack: Both .NET and Java.

Rationale: Some structures used by these actions were moved to the new EPA_TaskBoxExtension.

Workaround: Simply refresh all references to the EPA_Taskbox.

Export to Excel

  1.  

Issue: All third-party applications that consume Excel files generated by the OutSystems Platform might not work as expected.

Stack: Both .NET and Java.

Rationale: To make dates and times uniform across the OutSystems Platform, the RecordListToExcel widget now exports dates and times with the format configured in Service Center.

Workaround: Change all third-party applications that consume Excel files generated by the OutSystems Platform, to use the new date and time formats.

  1.  

Issue: All third-party applications that consume Excel files generated by the OutSystems Platform might not work as expected, either if they were expecting null dates to be 1900-01-01, or if they are expecting empty cells to be text.

Stack: Both .NET and Java.

Rationale: To make the RecordListToExcel widget work as expected, null dates and null times are exported as empty cells in the Excel file.

Workaround: Change all third-party applications that consume Excel files generated by the OutSystems Platform, to deal with blank cells for text, date and time data types.

Sessions

  1.  

Issue: If you had configured the session timeout in JBoss by changing the deployers/jbossweb.deployer/web.xml file, the default session timeout (3600 seconds) will now be used.

Stack: Java only.

Rationale: In order to centralize the configurations, the Java stack of the OutSystems Platform was changed. The request timeout and session timeout are now configured in the /etc/.java/.systemPrefs/outsystems/prefs.xml file.

Workaround: Change the /etc/.java/.systemPrefs/outsystems/prefs.xml file, by setting the 'OutSystems.HubEdition.SessionTimeout' parameter with the session timeout you had specified in the deployers/jbossweb.deployer/web.xml file.

  1.  

Issue: Load balancers configured to use sticky sessions will misbehave.

Stack: Java only.

Rationale: The session cookie used by the Java application servers was renamed from JSESSIONID to OSSESSIONID.

Workaround: Review the load balancer configurations of your infrastructure and replace JSESSIONID by OSSESSIONID.

Web Services

  1.  

Issue: When upgrading, eSpaces that contain Web Services without actions will be left with errors.

Stack: Both .NET and Java.

Rationale: To avoid programming errors, Service Studio no longer allows creating Web Services without specifying any action.

Workaround: Simply delete the empty Web Services to fix the errors.

  1.  

Issue:  Web References to WSDLs that specify policies might fail at runtime, when being invoked.

Stack: Java only.

Rationale: In previous versions of the Java stack of the OutSystems Platform, policies specified in the WSDL of Web Services were disregarded at runtime. Starting in version 8, the Java application server validates the policies specified.

Workaround: To overcome this issue, edit the WSDL to remove the specified policies, and import the WSDL into Service Studio from the file system.

  1.  

Issue: After the upgrade, new Web Services will be created with Document/Literal SOAP binding, while existing Web Services will not be changed, but issue a warning. In version 9.0, OutSystems will stop providing support for web services with RPC/Encoded SOAP bindings.

Stack: Java only.

Rationale: To follow the web standards, OutSystems is deprecating web services with RPC/Encoded SOAP bindings. New Web Services deployed by the Java stack of the OutSystems Platform, will be exposed with Document/Literal SOAP bindings, instead of RPC/Encoded SOAP bindings

Workaround: To upgrade existing Web Services, in Service Studio, copy and paste the existing Web Service to create a new Web Service with Document/Literal SOAP binding. Refresh all applications consuming this Web Service to start using the newly available Web Service. After all consumers have been updated, you can then delete the old Web Service.

  1.  

Issue: After the upgrade, integrations with the OutSystems Platform that rely on Web Services will stop working.

Stack: Java only.

Rationale: To follow the web standards, OutSystems Platform APIs that are exposed as web services were changed to use Document/Literal SOAP bindings, instead of RPC/Encoded.

Workaround: Refresh the Web References of all applications using these APIs to start using the new Web Services.

Logs

  1.  

Issue: In the unlikely event that JBoss crashes while there are messages to be processed by the Log Server, these messages will be lost.

Stack: Java only.

Rationale: Due to the continuously increasing size of H2 queues, even when the messages were already consumed by the Log Server, and the overload that it caused to JBoss, the current version of the Java version of OutSystems Platform was changed to hold the message queue in memory, instead of saving it to disk

Workaround: To continue saving the messages in a persistent way, change the $JBOSS_HOME/server/outsystems/deployer/h2-ds.xml file by setting the connection-url element with the appropriate jdbc value.

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.

Side Effects

  1.  

Side Effect: The Service Studio canvas background is now white, when editing Web Blocks. Designing Web Blocks with a dark background color might be more difficult.

Stack: Both .NET and Java.

Rationale: To allow developers to easily use the grid inside Web Blocks.

Workaround: To overcome this limitation, adapt the following style and add it to the application theme:

For version 8.0 through 8.0.1:

html body.OUTSYSTEMS_INTERNAL_WEBBLOCK_BODY { -servicestudio-background-color: black; }

For version 8.0.1 onwards:

html[data-ss-kind='Nodes.WebBlock']>body { -servicestudio-background-color: black !important; }

  1.  

Side Effect: the application switcher now displays the available applications with a click, instead of hovering with the mouse. End-users will have to click to access the application list

Stack: Both .NET and Java.

Rationale: Improve the support for mobile devices.

  1.  

Side Effect: In previous versions, when using the MobileAddToIPhoneHomeBubble from RichWidgets, if the end-user added the bookmark to the home screen, the bubble would automatically close. In the current version the end-user still needs to dismiss the bubble after adding the bookmark to the home screen.

Rationale: Improve the security of the component.

  1.  

Side Effect: In previous versions of the OutSystems Platform, even if an input widget had the 'Visible' property set to false, it would still contribute to the Edit Record 'Valid' runtime property. For behavior consistency, the current version of the OutSystems Platform disregards input widgets that have the 'Visible' property set to false, when calculating the Edit Record 'Valid' property. This change impacts few applications: applications that implemented this pattern would always have the Edit Record invalid, since the inputs would not be filled in.

Stack: Both .NET and Java.

Rationale: Widgets that are not rendered should not affect the Edit Record ‘Valid’ property.

  1.  

Side Effect: The XML extension no longer distributes the 'serialization.xsd' resource. In the unlikely situation that an application tries to access this resource, the access will fail.

Stack: Both .NET and Java.

Rationale: This resource was not being used by any application, and presented a security risk.

  1.  

Side Effect:  The OutSystems Platform 8 uses reset stylesheets that override the 'Border' property of Table widgets. For this reason this property was removed from Service Studio.

All tables using this property are changed during the upgrade to use equivalent advanced properties.

Stack: Both .NET and Java.

Rationale: Make the applications created by the OutSystems Platform render uniformly across different browsers.

Workaround: If you want to continue styling this property, either create a new CSS style or use the extended properties for the table.

  1.  

Side Effect: In previous versions, a new line was placed below each Web Block instance in the .NET stack of the OutSystems Platform. To fix problems presented in some browsers, the current version does not place a new line after Web Blocks. Check you applications to see if they render as expected.

Stack: .NET only.

Rationale: Make the .NET and Java stacks consistent.

Workaround: In the unlikely scenario that this change is causing problems, please contact OutSystems support.

  1.  

Side Effect (introduced in 8.0.1): IIS now sends the header “Cache-Control:max-age=2592000” in the response. This may cause browsers to use cached versions of static files (images, css, …), even after they are changed at the server.

Stack: .NET only.

Rationale: This change greatly improves the performance of web applications. It was already a performance tuning recommendation in the installation checklist of the previous versions, and now is done automatically for you.

Workaround: To revert to the old behavior, do one of the following:

  • Move the files to the database, or an external provider;
  • Create a cache invalidation scheme when sending to the client (e.g. /myapp/myfile.txt?RandomNumber=321321);
  • Go to IIS Manager > Default Web Site > HTTP Response Headers > Set Common Headers > Uncheck the “Expire Web Content” checkbox;
  • Use Service Center Factory Configuration to revert a specific eSpace to the old behavior.
  1.  

Side Effect (introduced in 8.0.1): The Rich Widgets GetApplicationName function was changed to stop returning the name of the eSpace if the eSpace was set as Front-Office or empty string if the eSpace was not set has Front-Office.

The function now returns the name of the application where the eSpace module is.

Stack: Both .NET and Java.

Rationale: It's the expected behavior.

Workaround: To revert to the old behavior, simply delete the function from where it is being used.

 

  • Was this article helpful?